Como nota: he leído los documentos de Redux (Baobab, también), y he hecho una buena cantidad de Google y pruebas.
¿Por qué se sugiere que una aplicación Redux tenga solo una tienda?
Entiendo las ventajas y desventajas de una configuración de tienda única frente a una configuración de tienda múltiple ( 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 tanto para Redux, casi hasta el punto de sonar obligatorio ( aunque nada nos impide hacer varias tiendas )?
EDITAR: comentarios después de convertir a una sola tienda
Después de unos meses trabajando con redux en lo que muchos considerarían un SPA complejo, puedo decir que la estructura de una sola tienda ha sido un placer trabajar con ella.
Algunos puntos que podrían ayudar a otros a entender 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 una sola tienda. Evita todos los cuestionamientos sobre dónde podrían estar los problemas estatales.
- es rápido : nuestra tienda actualmente tiene cerca de 100 reductores, si no más. Incluso en ese caso, solo un puñado de reductores procesa datos en cualquier envío dado, los otros simplemente devuelven el estado anterior. El argumento de que una tienda enorme / compleja ( nbr de reductores ) es lenta es bastante discutible. Al menos no hemos visto ningún problema de rendimiento a partir de ahí.
- depuración amigable : si bien este es un argumento muy convincente para usar redux como un todo, también se aplica a una tienda individual frente a una tienda múltiple. 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 redux-logger ) nunca hemos dedicado más de unos minutos a un problema de estado 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 solo un gran dolor. En segundo lugar, porque determina en gran medida cómo usará y consultará los datos de su aplicación para cualquier proceso. Hay muchas sugerencias sobre cómo estructurar una tienda. En nuestro caso, encontramos que lo siguiente es 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 este comentario ayude a otros.
EDIT 2 - herramientas útiles de la tienda
Para aquellos de ustedes que se han estado preguntando cómo administrar "fácilmente" una sola tienda , lo que puede volverse complejo rápidamente. Hay herramientas que ayudan a aislar las dependencias estructurales / lógica de su tienda.
Hay Normalizr que normaliza sus datos en función de un esquema. Luego proporciona una interfaz para trabajar con sus datos y buscar otras partes de sus datos id, de forma muy similar a un diccionario.
Sin conocer Normalizr en ese momento, construí algo en la misma línea. relational-json toma un esquema y devuelve una interfaz basada en tablas ( un poco como una base de datos ). La ventaja de relational-json es que su estructura de datos hace referencia dinámica a otras partes de sus datos ( esencialmente, 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.