Redux: varias tiendas, ¿por qué no?
Como nota: leí los documentos de Redux (también Baobab) y busqué en Google y probé una buena cantidad.
¿Por qué se recomienda tanto que una aplicación Redux tenga una sola tienda?
Entiendo los pros y los contras de una configuración de una sola tienda frente a una configuración de varias tiendas ( hay muchas preguntas y respuestas sobre SO sobre este tema ).
En mi opinión, esta decisión arquitectónica pertenece a los desarrolladores de aplicaciones en función de las necesidades de sus proyectos. Entonces, ¿por qué se recomienda con tanta fuerza para Redux, casi hasta el punto de parecer obligatorio ( aunque nada nos impide crear varias tiendas )?
EDITAR: comentarios después de la conversión a tienda única
Después de unos meses trabajando con redux en lo que muchos considerarían un SPA complejo, puedo decir que ha sido un verdadero placer trabajar con la estructura de una sola tienda.
Algunos puntos que podrían ayudar a otros a comprender por qué una sola tienda frente a muchas tiendas es una cuestión discutible en muchos, muchos casos de uso:
- es confiable : utilizamos selectores para explorar el estado de la aplicación y obtener información relevante para el contexto. Sabemos que todos los datos necesarios están en un solo almacén. Evita todo cuestionamiento sobre dónde podrían estar las cuestiones estatales.
- Es rápido : nuestra tienda dispone actualmente de cerca de 100 reductores, si no más. Incluso con ese recuento, solo un puñado de reductores procesan datos en un envío determinado, los demás simplemente devuelven el estado anterior. El argumento de que una tienda enorme/compleja ( núm. de reductores ) es lenta es bastante discutible. Al menos no hemos visto ningún problema de rendimiento procedente de ahí.
- amigable con la depuración : si bien este es un argumento muy convincente para usar redux en su conjunto, también se aplica a una sola tienda o a varias tiendas. Al crear una aplicación, es probable que tenga errores de estado en el proceso ( errores del programador ), es normal. El PITA es cuando esos errores tardan horas en depurarse. Gracias a la tienda única ( y al redux-logger ), nunca hemos dedicado más de unos minutos a un problema estatal determinado.
algunos consejos
El verdadero desafío al construir su tienda redux es decidir cómo estructurarla . En primer lugar, porque cambiar la estructura en el futuro es simplemente un gran dolor. En segundo lugar, porque determina en gran medida cómo utilizará y consultará los datos de su aplicación para cualquier proceso. Hay muchas sugerencias sobre cómo estructurar una tienda. En nuestro caso encontramos lo siguiente como ideal:
{
apis: { // data from various services
api1: {},
api2: {},
...
},
components: {} // UI state data for each widget, component, you name it
session: {} // session-specific information
}
Esperemos que estos comentarios ayuden a otros.
EDITAR 2: herramientas útiles de la tienda
Para aquellos de ustedes que se han estado preguntando cómo administrar "fácilmente" una sola tienda , lo cual puede volverse complejo rápidamente. Existen herramientas que ayudan a aislar las dependencias/lógicas estructurales de su tienda.
Existe Normalizr que normaliza sus datos según un esquema. Luego proporciona una interfaz para trabajar con sus datos y recuperar otras partes de sus datos id, de manera muy similar a un Diccionario.
Sin conocer Normalizr en ese momento, construí algo similar. relacional-json toma un esquema y devuelve una interfaz basada en tablas ( un poco como una base de datos ). La ventaja de json relacional es que su estructura de datos hace referencia dinámicamente a otras partes de sus datos ( básicamente, puede atravesar sus datos en cualquier dirección, al igual que los objetos JS normales ). No es tan maduro como Normalizr, pero lo he estado usando con éxito en producción durante algunos meses.
Hay casos extremos en los que es posible utilizar varias tiendas (por ejemplo, si tiene problemas de rendimiento al actualizar listas de miles de elementos que están en pantalla al mismo tiempo muchas veces por segundo). Dicho esto, es una excepción y en la mayoría de las aplicaciones nunca necesitas más de una tienda.
¿Por qué enfatizamos esto en los documentos? Debido a que la mayoría de las personas con experiencia en Flux asumirán que múltiples tiendas son la solución para hacer que el código de actualización sea modular. Sin embargo, Redux tiene una solución diferente para esto: composición reductora.
Tener múltiples reductores que se dividen en un árbol de reductores es la forma de mantener las actualizaciones modulares en Redux. Si no reconoce esto y opta por varias tiendas sin comprender primero completamente la composición del reductor, se perderá muchos beneficios de la arquitectura de tienda única de Redux:
El uso de la composición del reductor facilita la implementación de "actualizaciones dependientes" al
waitForestilo de Flux al escribir un reductor llamando manualmente a otros reductores con información adicional y en un orden específico.Con una sola tienda, es muy fácil persistir, hidratarse y leer el estado. La representación del servidor y la captación previa de datos son triviales porque solo hay un almacenamiento de datos que debe llenarse y rehidratarse en el cliente, y JSON puede describir su contenido sin preocuparse por el ID o el nombre de la tienda.
Una sola tienda hace posibles las funciones de viaje en el tiempo de Redux DevTools. También facilita las extensiones comunitarias como redux-undo o redux-optimist porque operan en el nivel reductor. Estos "potenciadores reductores" no se pueden escribir para las tiendas.
Una única tienda garantiza que las suscripciones se llamen sólo después de que se haya procesado el envío. Es decir, cuando se notifica a los oyentes, el estado se ha actualizado por completo. En muchas tiendas no existen tales garantías. Ésta es una de las razones por las que Flux necesita la
waitFormuleta. Con una sola tienda, este no es un problema que se vea en primer lugar.Sobre todo, varias tiendas son innecesarias en Redux (excepto en los casos extremos de rendimiento que, de todos modos, se supone que debes perfilar primero). Lo convertimos en un punto importante en los documentos, por lo que lo alentamos a aprender la composición del reductor y otros patrones de Redux en lugar de usar Redux como si fuera Flux y perder sus beneficios.
En algunas aplicaciones empresariales muy grandes con cientos o miles de reductores, suele ser útil pensar en diferentes áreas de la aplicación como aplicaciones completamente separadas. En esos casos (donde realmente son varias aplicaciones las que comparten un nombre de dominio), utilizo varias tiendas.
Por ejemplo, tiendo a tratar las siguientes áreas de funcionalidad común como aplicaciones separadas:
- Administración
- Análisis/datos frente a paneles de control
- Gestión de facturación y flujos de compra.
- Equipo de cuentas empresariales/gestión de permisos
Si alguna de esas cosas es pequeña, manténgala como parte de la aplicación principal. Si crecen mucho (como lo hacen algunas herramientas de análisis y administración de cuentas empresariales), divídalos.
La mejor manera de administrar aplicaciones muy grandes es tratarlas como una composición de muchas aplicaciones más pequeñas.
Si su aplicación tiene menos de ~50k LOC, probablemente debería ignorar este consejo y seguir el consejo de Dan.
Si su aplicación tiene más de 1 millón de LOC, probablemente debería dividir las miniaplicaciones, incluso si las mantiene en un repositorio mono.
