Redux - plusieurs magasins, pourquoi pas?
Remarque: j'ai lu la documentation de Redux (également de Baobab) et effectué une bonne partie de la recherche sur Google et des tests.
Pourquoi est-il si fortement suggéré qu'une application Redux ait un seul magasin?
Je comprends les avantages et les inconvénients d’une configuration à magasin unique par rapport à une configuration à plusieurs magasins (Il existe de nombreuses questions et réponses sur SO à ce sujet).
OMI, 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 (même si rien ne nous empêche de faire plusieurs magasins)?
EDIT: retour après conversion en magasin unique
Après quelques mois de travail avec Redux sur ce que beaucoup considèrent 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 un seul magasin par rapport à plusieurs est une question sans objet dans de nombreux cas d'utilisation:
- c'est fiable : nous utilisons des sélecteurs pour naviguer dans 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 de poser des questions sur les problèmes potentiels des États.
- c'est rapide : notre magasin compte actuellement près de 100 réducteurs, voire plus. Même à ce compte, seule une poignée de réducteurs traitent les données d’une expédition donnée, les autres ne font que renvoyer l’état précédent. L'argument selon lequel un magasin énorme/complexe (nbr de réducteurs) est lent est à peu près discutable. Au moins, nous n’avons constaté aucun problème de performances.
- debugging friendly : bien qu’il s’agisse d’un argument très convaincant pour utiliser redux dans son ensemble, il s’applique également à magasin unique plutôt qu’à magasin multiple. Lors de la création d'une application, le processus comporte inévitablement des erreurs d'état (erreurs du programmeur), c'est normal. Le PITA est lorsque ces erreurs prennent des heures pour déboguer. Grâce au magasin unique (et redux-logger), nous n'avons jamais consacré plus de quelques minutes à un problème d'état donné.
quelques pointeurs
Le véritable défi dans la construction de votre magasin Redux est de décider comment structurer it. Premièrement, le fait de changer de structure sur la route n’est que très pénible. Deuxièmement, car il détermine en grande partie votre utilisation et interroge les données de votre application pour n’importe quel processus. Il y a beaucoup de suggestions sur la manière de structurer un magasin. Dans notre cas, nous avons trouvé l’idéal suivant:
{
apis: { // data from various services
api1: {},
api2: {},
...
},
components: {} // UI state data for each widget, component, you name it
session: {} // session-specific information
}
Espérons que ces commentaires aideront les autres.
EDIT 2 - outils utiles pour le magasin
Pour ceux d'entre vous qui se demandent comment gérer "facilement" un magasin unique, qui peut devenir rapidement complexe. Il existe des outils permettant d’isoler les dépendances structurelles/la logique de votre magasin.
Il existe Normalizr qui normalise vos données en fonction d’un schéma. Il fournit ensuite une interface pour travailler avec vos données et extraire d'autres parties de vos données de id, un peu comme un dictionnaire.
Ne sachant pas Normalizr à l'époque, j'ai construit quelque chose dans le même sens. relational-json prend un schéma et renvoie une interface basée sur Table (un peu comme une base de données). Relational-json présente l'avantage que votre structure de données référence de manière dynamique d'autres parties de vos données (vous pouvez essentiellement parcourir vos données dans n'importe quelle direction, comme pour 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.
Dans certains cas Edge, vous pouvez utiliser plusieurs magasins (par exemple, si vous rencontrez des problèmes de performances lors de la mise à jour de listes de milliers d'éléments affichées à l'écran plusieurs fois par seconde). Cela dit, c'est une exception et dans la plupart des applications, vous n'avez jamais besoin de plus d'un magasin.
Pourquoi insistons-nous sur cela dans la documentation? Parce que la plupart des gens venant de Flux auront supposons que plusieurs magasins sont la solution pour rendre le code de mise à jour modulaire. Cependant, Redux a une solution différente pour cela: la composition de réducteur.
Le fait de conserver des mises à jour modulaires dans Redux consiste à diviser davantage les réducteurs en une arborescence de réducteurs. Si vous ne le reconnaissez pas et que vous optez pour plusieurs magasins sans d'abord bien comprendre la composition des réducteurs, vous manquerez de nombreux avantages de l'architecture à magasin unique de Redux:
L'utilisation de la composition de réducteur facilite l'implémentation de "mises à jour dépendantes" à la
waitFordans Flux en écrivant un réducteur appelant manuellement les autres réducteurs avec des informations supplémentaires et dans un ordre spécifique.Avec un seul magasin, il est très facile de persister, de s'hydrater et de lire l'état. Le rendu sur le serveur et la pré-extraction des données sont simples car il n’ya qu’un seul stockage de données à remplir et à réhydrater sur le client, et JSON peut décrire son contenu sans se préoccuper de l’ID ou du nom du magasin.
Un seul magasin permet aux fonctions de voyage dans le temps de Redux DevTools. Cela facilite également les extensions de communauté telles que redux-undo ou redux-optimist car elles fonctionnent au niveau réducteur. De tels "amplificateurs réducteurs" ne peuvent pas être écrits pour les magasins.
Un seul magasin garantit que les abonnements sont appelés uniquement après le traitement de l'envoi. C'est-à-dire qu'au moment où les auditeurs sont informés, l'état a été entièrement mis à jour. Avec de nombreux magasins, il n'y a pas de telles garanties. C'est l'une des raisons pour lesquelles Flux a besoin de la
waitForbéquille. Avec un seul magasin, ce n'est pas un problème que vous voyez en premier lieu.Surtout, plusieurs magasins ne sont pas nécessaires dans Redux (à l'exception des cas Edge de performance que vous êtes censés d'abord profiler de toute façon). Nous en faisons un point important dans la documentation. Nous vous encourageons donc à apprendre la composition des réducteurs et d’autres modèles Redux au lieu d’utiliser Redux comme si c’était Flux et de perdre ses avantages.
Dans certaines applications d'entreprise très grandes avec des centaines, voire des milliers, de réducteurs, il est souvent utile de considérer les différents domaines de l'application comme des applications entièrement séparées. Dans ces cas (où plusieurs applications partagent un même nom de domaine), j'utilise plusieurs magasins.
Par exemple, j’ai tendance à traiter les fonctionnalités communes suivantes comme des applications distinctes:
- Admin
- Analytics/data vis dashboards
- Gestion de la facturation et des flux d'achat
- Compte d'entreprise/gestion des autorisations
Si certaines de ces choses sont petites, conservez-les simplement dans l'application principale. S'ils deviennent très volumineux (comme le font certains outils d'analyse et de gestion de comptes d'entreprise), séparez-les.
La meilleure façon de gérer de très grandes applications consiste à les traiter comme une composition de nombreuses applications plus petites.
Si votre application est inférieure à ~ 50k LOC, vous devriez probablement ignorer ce conseil et suivre celui de Dan.
Si votre application dépasse 1 million de LOC, vous devriez probablement scinder les mini-applications, même si vous les conservez dans un référentiel mono.
Plusieurs magasins peuvent être utiles dans les cas d'utilisation suivants 1. Si vous avez des composants volumineux indépendants les uns des autres en termes de structure de données, de comportement et de contexte d'application. L'isolation de ces composants facilite la gestion de vos données et de votre flux d'applications. Il aide également au développement et à la maintenance indépendants de vos composants . 2. Problèmes de performances: ce n'est pas un cas d'utilisation typique, mais si certains de vos composants sont mis à jour très fréquemment et n'ont aucun impact sur les autres composants, vous pouvez probablement utiliser différents magasins.
Dans tous les autres cas, il n'est peut-être pas nécessaire d'avoir plusieurs magasins. Comme le dit Dan, créer des compositions réductrices réfléchies peut s’avérer une meilleure solution.
Cette décision architecturale appartient aux développeurs d'applications basés sur les besoins de leurs projets
Vous vivez dans votre propre monde. Je rencontre des gens qui utilisent redux, parce que c'est populaire, tous les jours. Vous ne pouvez même pas imaginer combien de projets ont été démarrés sans avoir à prendre de décision. Je déteste les approches redux, mais je dois les utiliser, car les autres développeurs ne connaissent rien d’autre. C'est juste une bulle épique gonflée par Facebook.
- _ {Ce n'est pas fiable} _ car certaines parties du magasin ne sont pas isolées.
- C'est inefficace} _ parce que vous clonez et parcourez des hash trie. Lorsque les mutations deviennent arithmétiques, la complexité augmente géométriquement. Vous ne pouvez pas le réparer en refacturant les réducteurs, les sélecteurs, etc. Vous devez diviser votre test.
- _ {Quand cela devient lent} personne ne veut le scinder en applications séparées avec magasins séparés. Personne ne veut dépenser de l'argent en refactoring. Les gens sont généralement convertissant certains composants intelligents en dump} et c'est tout. Savez-vous quel avenir attend les développeurs de Redux? Ils vont maintenir ces enfers.
- Ce n'est pas un outil de débogage facile. Il est difficile de déboguer des connexions entre des parties de magasin virtuellement isolées. Il est très difficile même d’analyser l’ampleur de ces connexions.
Imaginons que vous ayez plusieurs magasins Redux. Vous interromprez le flux de données unidirectionnel. Vous réaliserez immédiatement combien de liens vous avez entre les magasins. Vous pouvez souffrir de ces connexions, vous battre avec des dépôts circulaires, etc.
Un seul magasin immuable à flux unidirectionnel n’est pas un élixir pour toutes les maladies. Si vous ne voulez pas maintenir l'architecture du projet, vous en souffrirez quand même.
Avoir un magasin à Redux est ce dont nous avons vraiment besoin dans de nombreux cas. J'ai utilisé Redux et Flux et je suis convaincu que Redux fait le travail mieux!
N'oubliez pas que la boutique est dans un objet JavaScript. Par conséquent, même si vous n'avez qu'une seule boutique, elle peut être facilement étendue et réutilisée. Avoir une seule boutique facilite grandement la navigation à l'aide des outils de développement Redux et ne pas être mélangée. grandes applications ...
De plus, le concept de magasin unique imite la base de données pour nous, source de vérité que vous pouvez modifier et accéder à la mémoire du navigateur ...
Si l’ensemble de l’application est bien gérée, un magasin peut suffire à gérer l’ensemble du statut de l’application ...
pourquoi nous ne pouvons pas utiliser plusieurs magasins en utilisant Redux ????
Ceci n'est pas nécessaire sous Redux car la séparation entre les domaines de données est déjà réalisée en scindant un seul réducteur en un plus petit réducteurs.
Puis-je ou dois-je créer plusieurs magasins? Puis-je importer directement mon magasin et l'utiliser moi-même dans des composants?
Le modèle Flux d'origine décrit la présence de plusieurs «magasins» dans une application, chacun contenant une zone différente de données de domaine. Cela peut entraîner des problèmes tels que le besoin d'avoir un magasin “waitFor” un autre magasin à mettre à jour.
Ceci n'est pas nécessaire sous Redux car la séparation entre les domaines de données est déjà réalisée en scindant un seul réducteur en un plus petit réducteurs.
Comme pour plusieurs autres questions, il est possible de créer plusieurs magasins Redux distincts dans une page, mais le modèle prévu doit avoir un seul magasin. Le fait d'avoir un magasin unique permet d'utiliser Redux DevTools, simplifie la persistance et la réhydratation des données et simplifie la logique de souscription.
Certaines raisons valables pour utiliser plusieurs magasins dans Redux peuvent inclure:
Résolution d'un problème de performances causé par des mises à jour trop fréquentes d'une partie de l'état, confirmée par le profilage de l'application . Isolement d'une application Redux en tant que composant d'une application plus grande, auquel cas vous pouvez créer un magasin par racine instance de composant . Cependant, la création de nouveaux magasins ne devrait pas être votre premier instinct, surtout si vous venez d'un fond Flux. Essayez d’abord la composition de réducteur et n’utilisez que plusieurs magasins si cela ne résout pas votre problème.
De même, bien que vous puissiez référencer votre instance de magasin en l'important directement, il ne s'agit pas d'un modèle recommandé dans Redux. Si vous créez une instance de magasin et l'exportez d'un module, elle deviendra un singleton. Cela signifie qu'il sera plus difficile d'isoler une application Redux en tant que composant d'une application plus grande, si cela est nécessaire, ou d'activer le rendu du serveur, car sur le serveur, vous voulez créer des instances de magasin distinctes pour chaque demande.