Las dificultades de trabajar con Redux y su solución.

Redux entre nosotros

Este es uno de los gestores estatales más populares.

Es fácil de usar, transparente y predecible. Con él, puede organizar el almacenamiento y la modificación de datos. Y si suponemos que la acción y el reductor son parte de redux , podemos decir sin exagerar que él es el titular de toda la lógica de dominio (también conocida como lógica de negocios) de nuestras aplicaciones.

¿Todo es tan color de rosa?

A pesar de su simplicidad y transparencia, usar redux tiene una serie de inconvenientes ...

Los datos en estado ` redux` se encuentran en un simple objeto javascript y se pueden obtener de la manera habitual, solo necesita conocer la ruta .

Pero, ¿cómo organizamos estos datos? Solo hay 2 opciones: una lista plana y un modelo jerárquico .

Una lista plana es una excelente opción para una aplicación en la que solo hay, por ejemplo, un contador ... Para algo más serio, necesitamos una estructura jerárquica. Además, cada nivel de datos tendrá menos conocimiento que el anterior. Todo es lógico y comprensible, pero el camino hacia los datos se vuelve compuesto .



La presencia de una estructura de datos jerárquica y la falta de un enfoque modular para estos datos lleva al hecho de que en cada lugar donde se usan estos datos, es necesario conocer el camino completo hacia ellos. En otras palabras, esto crea una cohesión de la estructura de almacenamiento de datos y sus estructuras de visualización y conduce a dificultades con la refactorización de ruta y / o la reorganización de la estructura de datos.




Otro desafío es la prueba. Sí, hay un artículo separado en la documentación para las pruebas redux , pero ahora no se trata de probar artefactos individuales como reductor y creador de acción .

Los datos, las acciones y los reductores suelen estar interconectados. Y un árbol de datos lógicamente relacionados a menudo es servido por varios reductores , que deben ser probados, incluso juntos.

Agregue a esta lista los selectores , cuyos resultados dependen en particular del trabajo del reductor ...

En general, puede probar todo esto, pero debe lidiar con un montón de artefactos que están interconectados solo por lógica y convenciones.

Y qué pasa si creamos una estructura, por ejemplo, con datos de usuario, incluidas listas de amigos, canciones favoritas y cualquier otra cosa, así como la funcionalidad de cambiarlos a través de reductores de acción . Quizás incluso escribimos un montón de pruebas para toda esta funcionalidad. Y ahora, en el próximo proyecto, necesitamos lo mismo ...

¿Cómo codificar a bajo precio?

Busca una solución

Para descubrir cómo preservar los beneficios de redux y deshacerse de las desventajas descritas, debe comprender de qué depende en el ciclo de vida de los datos:

• Eventos de informes de acción , personalizados y más
• El reductor reacciona a la acción y cambia o no cambia el estado de los datos
• El cambio de datos es un evento en sí mismo y puede causar que otros datos cambien.

El controlador en este caso es una abstracción que procesa tanto las acciones del usuario como los cambios de datos en la tienda . No tiene que ser una clase separada en absoluto, por regla general, está dividido por componentes.

Combina todo el zoológico redux en una caja negra

Pero, ¿qué pasa si envolvemos la acción , el reductor y el selector en un módulo y le enseñamos a no depender de la ruta específica para la ubicación de sus datos?

¿Qué sucede si todas las acciones del usuario , por ejemplo, se confirman llamando al método de instancia: user.addFriend (friendId) ? Y los datos se obtienen a través de getter: user.getFriendsCount () ?

¿Qué sucede si podemos importar toda la funcionalidad del usuario con una simple importación ?

 const userModule from 'node_modules/user-module'; 

¿Es conveniente? Especialmente teniendo en cuenta que para esto no necesita escribir un montón de código adicional:
El paquete npm redux-module-creator proporciona toda la funcionalidad para crear módulos redux libremente acoplados, reutilizables y probados .

Cada módulo consta de un controlador , un reductor y una acción y tiene las siguientes características:

• se integra en la tienda a través de una llamada al método integrador, y para cambiar el lugar de integración, solo necesita cambiar el lugar de la llamada del integrador y su parámetro
  
  
  
• el controlador tiene una conexión con su parte de los datos en la tienda , recordando la ruta que se pasa al integrador () una vez. Esto elimina la necesidad de saberlo cuando se usan datos.
  
  
  
• el controlador es el titular de todos los selectores, adaptadores, etc. necesarios
• para realizar un seguimiento de los cambios, es posible suscribirse a los cambios en sus propios datos
• el reductor puede usar el contexto de llamada, una instancia del módulo y obtener de él el tipo de acción que pertenece al módulo. Esto elimina la necesidad de importar un montón de acciones y reduce la probabilidad de un error.
• Las acciones obtienen el contexto de uso, porque se convierten en parte de la instancia del módulo: ahora no es solo trainingFinished , sino readModule.actions.trainingFinished
• las acciones ahora existen en el espacio de nombres del módulo, que le permite crear eventos con el mismo nombre para diferentes módulos
• Cada módulo se puede instanciar varias veces, y cada instancia se integra en diferentes partes de la tienda
• Las acciones para diferentes instancias de módulos tienen diferentes tipos de acción : puede responder a eventos de una instancia específica

Como resultado, obtenemos un cuadro negro que puede administrar sus datos por sí mismo y tiene identificadores para comunicarse con código externo.

Al mismo tiempo, es el mismo redux , con su flujo de datos unidireccional, transparencia y previsibilidad.

Y dado que todos estos son el mismo redux y los mismos reductores , puede construir a partir de ellos cualquier estructura que requiera la lógica del dominio de la aplicación.