Remarque: j'ai lu les documents pour Redux (Baobab aussi) et j'ai fait une bonne partie de Google et des tests.
Pourquoi est-il si fortement suggéré qu'une application Redux n'ait qu'un seul magasin?
Je comprends les avantages / inconvénients d'une configuration à magasin unique par rapport à une configuration à magasins multiples ( il existe de nombreuses questions / réponses sur SO à ce sujet ).
IMO, cette décision architecturale appartient aux développeurs d'applications en fonction des besoins de leurs projets. Alors pourquoi est-il si fortement suggéré pour Redux, presque au point de paraître obligatoire ( bien que rien ne nous empêche de faire plusieurs magasins )?
EDIT: rétroaction après la conversion en magasin unique
Après quelques mois de travail avec Redux sur ce que beaucoup considéreraient comme un SPA complexe, je peux dire que la structure à magasin unique a été un pur plaisir de travailler avec.
Quelques points qui pourraient aider les autres à comprendre pourquoi le magasin unique par rapport à plusieurs magasins est une question théorique dans de nombreux cas d'utilisation:
- il est fiable : nous utilisons des sélecteurs pour parcourir l'état de l'application et obtenir des informations contextuelles. Nous savons que toutes les données nécessaires se trouvent dans un seul magasin. Cela évite toute remise en question de la situation des problèmes d'État.
- c'est rapide : notre magasin compte actuellement près de 100 réducteurs, sinon plus. Même à ce niveau, seule une poignée de réducteurs traitent les données sur une répartition donnée, les autres renvoient simplement l'état précédent. L'argument selon lequel un magasin énorme / complexe ( nombre de réducteurs ) est lent est à peu près théorique. Au moins, nous n'avons vu aucun problème de performance en provenance de là.
- débogage convivial : bien que ce soit un argument le plus convaincant pour utiliser redux dans son ensemble, il vaut également pour le magasin unique contre le magasin multiple. Lorsque vous créez une application, vous êtes lié à des erreurs d'état dans le processus ( erreurs de programmation ), c'est normal. Le PITA est lorsque ces erreurs mettent des heures à déboguer. Grâce au magasin unique ( et au redux-logger ), nous n'avons jamais passé plus de quelques minutes sur un problème d'état donné.
quelques conseils
Le vrai défi dans la construction de votre magasin redux est de décider comment le structurer . Tout d'abord, parce que changer de structure en cours de route n'est qu'une douleur majeure. Deuxièmement, car cela détermine en grande partie comment vous allez utiliser et interroger les données de votre application pour n'importe quel processus. Il existe de nombreuses suggestions sur la façon de structurer un magasin. Dans notre cas, nous avons trouvé que ce qui suit était idéal:
{
apis: { // data from various services
api1: {},
api2: {},
...
},
components: {} // UI state data for each widget, component, you name it
session: {} // session-specific information
}
J'espère que ces commentaires aideront les autres.
EDIT 2 - outils de magasin utiles
Pour ceux d'entre vous qui se demandent comment gérer "facilement" un seul magasin , ce qui peut rapidement devenir complexe. Il existe des outils qui aident à isoler les dépendances structurelles / la logique de votre magasin.
Il y a Normalizr qui normalise vos données en fonction d'un schéma. Il fournit ensuite une interface pour travailler avec vos données et récupérer d'autres parties de vos données id
, un peu comme un dictionnaire.
Ne connaissant pas Normalizr à l'époque, j'ai construit quelque chose dans le même sens. relationnel-json prend un schéma et renvoie une interface basée sur une table ( un peu comme une base de données ). L'avantage de relation-json est que votre structure de données référence dynamiquement d'autres parties de vos données ( essentiellement, vous pouvez parcourir vos données dans n'importe quelle direction, tout comme les objets JS normaux ). Ce n'est pas aussi mature que Normalizr, mais je l'utilise avec succès en production depuis quelques mois maintenant.