Quels sont les avantages d'utiliser store (ngrx) dans angular 2

Question

Je suis en train de travailler sur un angulaire 1.x.x projet et la réflexion sur la mise à niveau de mon code angulaire 2.

Maintenant, dans mon projet, j'ai de nombreux services(usine) pour la manipulation des données dont près de conserver les données en js tableaux(à la fois cache et de stockage) et le traitement de ces données à l'aide de soulignement pour la manipulation des tableaux.

J'ai constaté que de nombreux exemples dans angular2 à l'aide de ngrx.

Quels sont les avantages de l'utilisation de stocker les comparer à utiliser les services de données pour gérer les données?

Ai-je besoin de plusieurs magasin pour mon application si j'ai plusieurs type de données (stocks, commandes, clients...)?

Comment puis-je structure (conception) de mon application à traiter avec de multiples types de données comme celle-ci?

Answer 1

Même si votre question est principalement opinion, je peux vous donner quelques idées de pourquoi ngrx est un bon choix. Malgré que les gens en disant que ce n'est pas une bonne idée d'avoir toutes les de votre état de l'application dans un objet unique (un Seul État de l'Arbre). Cependant, à mon avis, votre état sera là, peu importe. Avec un magasin, c'est juste tout en une fois à l'endroit et les mutations sont explicites et suivis vs jonché partout et conservées localement par les composants. En outre, vous sélectionnez les propriétés spécifiques de votre magasin au sein de votre application, de sorte que vous pouvez sélectionner uniquement les données qui vous intéressent. Ensuite, si vous embrassez l'immuabilité dans votre réducteurs en retournant toujours un tableau, par exemple) et l'utilisation des Observables, vous pouvez faire usage de la ChangeDetectionStrategy OnPush. OnPush vous donne un bon boost de performance. Prenons un oeil à la figure suivante pris de l'officiel Angulaire docs:

Comme vous pouvez le voir, Angulaire Application est construite à l'aide d'un composant de l'architecture, ce qui résulte en une composante de l'arbre. OnPush sur un composant signifie que seulement si l'entrée modification des attributs, la détection de changement de scène. Par exemple, si Child B est OnPush et Child A est Default et vous changer quelque chose à l'intérieur d' Child A, Child Bs'changer de détecteur ne sera pas déclenché car aucun des attributs d'entrée ont changé. Toutefois, si vous modifiez quelque chose à l'intérieur d' Child B, Child A sera ré-rendu, car il a le défaut, remplacez le détecteur.

Autant sur les performances et le seul état de l'arbre. Un autre avantage de la banque est que vous pouvez réellement raison au sujet de votre code et les modifications de l'état. Donc, la réalité de la plupart Angulaire 1.x apps est à la portée de la soupe. Voici un joli graphique à partir d'un post de blog par Lukas Ruebbelke:

La photo montre assez bien. Un autre article de Tero Parviainen parle de comment il a amélioré ses Angulaire des applications en interdisant ng-controller. Que tout se rapporte à l'étendue de la soupe et de la gestion de la perpétuelle évolution est une tâche difficile. L' redux motivation est 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, et ce, à son tour, pourrait provoquer une autre vue de la mise à jour. À un certain point, vous n'avez plus à comprendre ce qui se passe dans votre application comme vous l'avez perdu le contrôle sur le quand, le pourquoi, et le comment de son état. Lorsqu'un système est opaque et non-déterministe, il est difficile de reproduire les bugs ou ajouter de nouvelles fonctionnalités.

En utilisant ngrx/magasin, vous pouvez réellement obtenir autour de ce problème, car vous aurez un clair de flux de données dans votre application.

Depuis ngrx est fortement inspiré par redux, je dirais que les mêmes principes s'appliquent:

• Source unique de la vérité
• L'état est en lecture seule
• Des modifications sont apportées avec les fonctions pures

Donc, à mon avis, le plus grand avantage est que vous êtes en mesure de suivre facilement l'interaction de l'utilisateur et de la raison sur les modifications de l'état parce que vous l'expédition des actions et ceux qui conduisent toujours à un endroit alors qu'avec la plaine de modèles, vous devez trouver tous les refernces et de voir ce qui change quoi et quand.

À l'aide de ngrx/store vous permet également d'utiliser devtools de voir le débogage de votre état de conteneurs et d'annuler les changements. Voyage dans le temps, je suppose, a été l'une des principales raisons pour redux et c'est assez difficile si vous utilisez de la plaine de vieux modèles.

La testabilité @muetzerich déjà mentionné est également un avantage de l'utilisation de ngrx/store. Les réducteurs sont de pures fonctions et les fonctions sont faciles à tester, parce qu'ils ont une entrée et simplement le retour d'une sortie et ne dépend pas des propriétés à l'extérieur de la fonction et n'ont pas d'effets secondaires, par exemple http appels, etc.

Pour passer à la ligne de fond, je dirais que n'avez pas besoin d'utiliser ngrx/store pour effectuer l'une de ces choses, mais vous serez lié à des restrictions (les trois principes mentionnés ci-dessus), qui fournissent un modèle commun et apporter de belles prestations.

Pour vos questions:

Ai-je besoin de plusieurs magasin pour mon application si j'ai plusieurs type de données (stocks, commandes, clients...)?

Non, je ne le suggèrent d'utiliser plusieurs magasins.

Comment puis-je structure (conception) de mon application à traiter avec de multiples types de données comme celle-ci?

Peut-être que ce post de blog par Tero Parviainen vous aide à comprendre comment la conception de votre magasin. Il explique comment la conception de l'état de l'application de l'arbre pour un exemple d'application.

Answer 2

Une belle explication sur le maximum de l'aide d'un magasin, vous pouvez trouver dans n' documentation

Centralisée, État Immuable

Tous pertinents de l'état de l'application existe en un seul endroit. Cela rend plus facile d'identifier des problèmes, comme un instantané de l'état au moment de l'erreur peut fournir des indications importantes et permettent de recréer des questions. Cela rend également notoirement difficiles problèmes tels que undo/redo négligeable dans le contexte d'un Magasin d'applications et permet outillage puissant.

Performance

Depuis que l'état est centralisée au niveau de la partie supérieure de votre application, les mises à jour de données peut s'écouler vers le bas à travers vos composants en s'appuyant sur des tranches de magasin. Angulaire 2 est construite de façon à optimiser sur un flux de données de l'arrangement, et pouvez désactiver la détection de changement dans les cas où les composants reposent sur des Observables qui n'ont pas émis de nouvelles valeurs. Dans des conditions optimales magasin de solution, ce sera la grande majorité de vos composants.

La testabilité

Toutes les mises à jour d'état sont traitées dans les réducteurs, qui sont de pures fonctions. Les fonctions pures sont extrêmement simples à tester, car il est tout simplement entrée dans le, valoir à l'encontre de sortie. Cela permet de tester des aspects les plus cruciaux de votre application sans se moque, des espions, ou d'autres trucs qui peuvent faire des tests à la fois complexes et sujettes à erreur.

Plusieurs magasins?

OMI, l'utilisation d'un magasin et d'ajouter vos types de données de propriétés dans votre magasin.

Answer 3

ngrx.magasin n'est qu'un composant/service sera de faire, avec des avantages supplémentaires. Jusqu'à présent, et je suis en début de travail à travers la façon dont cela vient, c'est ce que j'ai trouvé:

Il est vraiment facile d'obtenir un difficile à maintenir le désordre avec des services et des composants. Si vous avez des actions en cascade, des données complexes interactions et des appels à des endroits éloignés, en fin de structuration d'un service qui est presque identique à l'action-réducteur de magasin agencement dans ngrx. Petites fonctions pures, observables, etc. ngrx a déjà, pourquoi ne pas l'utiliser et le gain de la pensée et des modèles qu'il représente.

Si les forces ou les encourage à penser dans les petites testable fonctions. Pour disposer d'un réducteur ou plusieurs réducteurs pour un modérément complexes composant applique une discipline qui permet de supprimer tant de l'heure de consommer des pièges. Rien n'avale des heures comme à la poursuite d'un quasi multithread condition de concurrence découlant de la fonction de rappel de la file d'attente. Je suis sûr que cela peut arriver avec des réducteurs, mais il simplifie l'accès à la séquence d'appel et de l'état à des fins de débogage.

Le Angular2 modèle devient plus facile. Modèles avec la logique d'affichage, des composants comme un lieu de rassemblement de tous les morceaux que le modèle a besoin. Les Services deviennent de plus simple comme ils tout simplement faire des appels distants ou de manipuler les io de données à partir d'où qu'elle vienne. Ensuite, les actions et les réducteurs pour le maintien et la modification de l'état, qui déclenche toutes les autres parties pour répondre à la nouvelle état. J'ai trouvé qu'avec le composant/service modèle soit un commençaient à devenir de grands et complexes, avec le côté effet, il devient extrêmement difficile à déboguer. Mes services ont été terminant le stockage de l'état et de faire les données io.

Observables. Tout ce qui est observable dans rxjs.store, et qui est à la base d'un réactif de l'app. La structuration de l'état d'application comme un observable est parfois un peu arcanes ou pas très simple, mais à essayer de le comprendre et de le faire bien paie de gros dividendes dans le futur.

Le seul point négatif que je vois c'est que les réducteurs devenu extraordinairement grand 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 des paramètres, mais il ne fonctionne pas de cette façon. D'autre part, c'est là que la structure et l'état de l'application est exprimé dans tous ses détails, il est lié à beaucoup. Et quand quelque chose va mal, comme il se produira inévitablement, ayant une fonction pure comme la source du problème rend plus facile à repérer et de corriger.