Quels sont les avantages d'utiliser store (ngrx) dans angular 2
Je travaille sur un projet angular 1.x.x et réfléchis à la mise à niveau de mon code à angular 2.
Maintenant, dans mon projet, de nombreux services (usine) de traitement des données permettent de conserver presque les données dans des tableaux js (cache et stockage) et de traiter ces données à l'aide de traits de soulignement.
J'ai trouvé que de nombreux exemples dans angular2 utilisant ngrx.
Quels sont les avantages d'utiliser la comparaison de magasin pour utiliser des services de données pour traiter des données?
Ai-je besoin de plusieurs magasins pour mon application si j'ai plusieurs types de données (stock, commande, client ...)?
Comment structurer (concevoir) mon application pour gérer plusieurs types de données comme ceux-ci?
Même si votre question est principalement basée sur l'opinion, je peux vous donner quelques idées pour lesquelles Ngrx est un bon choix. Bien que certains disent que ce n’est pas une bonne idée d’avoir tout l’état de votre application dans un seul objet (arbre à un seul état). Cependant, à mon avis, votre état sera toujours là. Avec un magasin, il s’agit d’un point d’apparition unique et les mutations sont explicites et suivies au lieu d’être jalonnées et maintenues localement par des composants. En outre, vous sélectionnez des propriétés spécifiques dans votre magasin au sein de votre application, de sorte que vous ne pouvez sélectionner que les données qui vous intéressent. Si vous intégrez ensuite l'immuabilité dans vos réducteurs en renvoyant toujours un tableau par exemple et en utilisant Observables, vous pouvez utiliser ChangeDetectionStrategy OnPush. OnPush vous donne un coup de pouce pour améliorer vos performances. Jetons un coup d'œil à la figure suivante tirée du document officiel Angular docs :
Comme vous pouvez le constater, une application Angular est construite à l'aide d'une architecture de composants, ce qui génère une arborescence de composants. OnPush sur un composant signifie que, si les attributs d'entrée sont modifiés, la détection démarrera. Par exemple, si Child B est OnPush et que Child A est Default et que vous modifiez quelque chose à l'intérieur de Child A, Child B Ne sera pas déclenché car aucun attribut d’entrée n’a été modifié. Toutefois, si vous modifiez quelque chose à l’intérieur de Child B, Child A Sera restitué car il contient le changement par défaut. détecteur.
Tant de choses sur les performances et l’arbre à états unique. Un autre avantage du magasin est que vous pouvez réellement raisonner sur vos changements de code et d’état. La réalité de la plupart des Angular 1.x est donc scope soupe . Voici un joli graphique d'un - blog post par Lukas Ruebbelke:
La photo le montre plutôt bien. Un autre article de Tero Parviainen explique comment il a amélioré ses Angular en bannissant ng-controller. Tout cela concerne la portée et la gestion en constante évolution L’état est difficile. La motivation redux dit ce qui suit voir ici :
Si un modèle peut mettre à jour un autre modèle, une vue peut mettre à jour un modèle, qui met à jour un autre modèle, ce qui, à son tour, peut entraîner la mise à jour d'une autre vue. À un moment donné, vous ne comprenez plus ce qui se passe dans votre application car vous avez perdu le contrôle de quand, pourquoi et comment de son état. Lorsqu'un système est opaque et non déterministe, il est difficile de reproduire des bogues ou d'ajouter de nouvelles fonctionnalités.
En utilisant ngrx/store, vous pouvez réellement contourner ce problème car vous obtiendrez un flux de données clair dans votre application.
Puisque ngrx est fortement inspiré par redux, je dirais que les mêmes principes de base s’appliquent:
- Source unique de vérité
- State est en lecture seule
- Les changements sont faits avec des fonctions pures
Donc, à mon avis, le principal avantage est que vous pouvez facilement suivre les interactions des utilisateurs et expliquer les changements d’état, car vous envoyez toujours les actions et celles qui mènent au même endroit, alors qu’avec les modèles simples, vous devez trouver tous les refernces et voir quels changements quand.
L'utilisation de ngrx/store vous permet également d'utiliser devtools pour voir comment déboguer votre conteneur d'état et annuler les modifications. Les voyages dans le temps, je suppose, étaient l’une des principales raisons de redux et c’est assez difficile si vous utilisez de vieux modèles.
La testabilité mentionnée par @muetzerich constitue également un avantage de l'utilisation de ngrx/store. Les réducteurs sont des fonctions pures et sont faciles à tester, car ils prennent une entrée et renvoient simplement une sortie. Ils ne dépendent pas de propriétés extérieures à la fonction et n'ont aucun effet secondaire, par exemple. appels http, etc.
Pour aller au fond des choses, je dirais qu'il n'est pas nécessaire d'utiliser ngrx/store pour effectuer ces opérations, mais vous serez lié à des restrictions (les trois principes mentionnés ci-dessus) qui fournissent un schéma commun et apportent des avantages Nice. .
A vos questions:
Ai-je besoin de plusieurs magasins pour mon application si j'ai plusieurs types de données (stock, commande, client ...)?
Non, je ne suggérerais pas d'utiliser plusieurs magasins.
Comment structurer (concevoir) mon application pour gérer plusieurs types de données comme ceux-ci?
Peut-être que ceci article de blog de Tero Parviainen vous aide à comprendre comment concevoir votre magasin. Il explique comment concevoir l'arborescence d'état d'application pour un exemple d'application.
Une bonne explication sur les avantages d'utiliser un magasin que vous pouvez trouver ici documentation
État immuable et centralisé
Tous les états d'application pertinents existent au même endroit. Cela facilite la recherche des problèmes, puisqu’un instantané de l’état au moment d’une erreur peut fournir des informations importantes et faciliter la recréation de problèmes. Cela rend également des problèmes notoirement difficiles tels que des annuler/rétablir, dans le contexte d’une application Store, et permet un outillage puissant.
Performance
Étant donné que l'état est centralisé en haut de votre application, les mises à jour des données peuvent s'effectuer via vos composants en fonction des tranches de magasin. Angular 2 est conçu pour optimiser un tel agencement de flux de données et peut désactiver la détection des modifications dans les cas où les composants s'appuient sur des observables n'ayant pas émis de nouvelles valeurs. Dans une solution de stockage optimale, ce sera la grande majorité de vos composants.
Testabilité
Toutes les mises à jour d'état sont traitées dans des réducteurs, qui sont des fonctions pures. Les fonctions pures sont extrêmement simples à tester, car elles sont simplement entrées, comparées aux sorties. Cela permet de tester les aspects les plus cruciaux de votre application sans simulacres, espions ou autres astuces qui peuvent rendre les tests complexes et sujets aux erreurs.
Plusieurs magasins?
OMI utilise un magasin et ajoute vos types de données en tant que propriétés dans votre magasin.
ngrx.store fait ce qu'un composant/service bien conçu va faire, avec des avantages supplémentaires. Jusqu'ici, et je commence très tôt à comprendre comment cela se passe, voici ce que j'ai trouvé:
Il est très facile de créer un désordre intangible avec des services et des composants. Si vous avez des actions en cascade, des interactions de données complexes et des appels vers des sites distants, vous finissez par structurer un service presque identique à l'arrangement action-reducer-store de ngrx. Petites fonctions pures, observables, etc. ngrx l'a déjà, pourquoi ne pas l'utiliser et profiter de la pensée et des motifs qu'il représente.
Si force/encourage la réflexion dans de petites fonctions testables. Disposer un ou plusieurs réducteurs pour un composant moyennement complexe impose une discipline qui éliminera un si grand nombre de pièges qui prennent beaucoup de temps. Rien n’avale des heures comme la recherche d’une condition de concurrence quasi multithread découlant de la file d’appel. Je suis sûr que cela peut arriver avec les réducteurs, mais cela simplifie l'accès à la séquence d'appels et à l'état pour le débogage.
Le motif Angular2 devient plus facile. Modèles avec la logique d'affichage, composants constituant un lieu de rassemblement de tous les éléments dont le modèle a besoin. Les services deviennent plus simples car ils effectuent simplement des appels à distance ou gèrent le io pour les données d'où qu'elles viennent. Ensuite, les actions et les réducteurs pour maintenir et changer l’état, ce qui déclenche la réaction de toutes les autres parties au nouvel état. J'ai trouvé qu'avec un modèle de composant/service, l'un ou l'autre devenait gros et compliqué, avec comme conséquence qu'il devenait extrêmement difficile de déboguer. Mes services finissaient par stocker l’état et traiter les données.
Observables. Tout est observable dans rxjs.store, et c'est la base d'une application réactive. Structurer l'état d'une application en tant qu'observable est parfois un peu obscur ou pas très simple, mais le savoir et le faire bien le fait rapporte de gros dividendes plus tard.
Le seul point négatif que je peux voir, c'est que les réducteurs deviennent extrêmement volumineux très rapidement. Il semble y avoir beaucoup de situations où le même code avec des noms différents est répété et répété. Mon cerveau hurle 'fonction avec paramètres', mais ça ne marche pas comme ça. Par ailleurs, c’est ici que la structure et l’état de l’application sont exprimés dans tous ses détails, de sorte qu’il doit y en avoir beaucoup. Et lorsque quelque chose ne va pas, comme cela se produira inévitablement, le fait d’avoir une fonction pure comme source du problème facilite la recherche et la résolution des problèmes.