Angular 6 - Pourquoi utiliser @ ngrx / store plutôt que l'injection de service
Je suis récemment en train d'apprendre Angular 6 avec @ ngrx/store, alors que l'un des didacticiels consiste à utiliser @ ngrx/store pour la gestion de l'état, je ne comprends toutefois pas l'intérêt d'utiliser @ ngrx/stocker derrière la scène.
Par exemple, pour une simple action de connexion et d'inscription, précédemment en utilisant le service (appelons-le AuthService), nous pourrions l'utiliser pour appeler l'api backend, stocker "userInfo" ou "token" dans AuthService. , redirigez l'utilisateur vers la page "HOME" et nous pouvons injecter AuthService dans tout composant où nous avons besoin d'obtenir userInfo à l'aide de DI, le seul fichier AuthService gérant tout.
Maintenant, si nous utilisons @ ngrx/store, nous devons définir le Action/Etat/Réducteur/Effets/Sélecteur qui doit probablement écrire dans 4 ou 5 fichiers pour gérer l’action ou l’événement ci-dessus, puis parfois il faut quand même appeler le backend api en utilisant le service, ce qui semble beaucoup plus compliqué et redondant ...
Dans un autre scénario, , je vois même que certaines pages utilisent @ ngrx/store pour stocker l'objet ou la liste d'objets comme des données de grille. , est-ce que c'est pour une sorte d'utilisation de magasin en mémoire?
Revenons donc à la question, pourquoi utilisons-nous @ ngrx/store over service enregistrement magasin ici dans Angular project? Je sais que c'est pour "STATE MANAGEMENT "utilisation, mais quelle est exactement la" GESTION D'ÉTAT "? Est-ce quelque chose comme le journal des transactions et quand en avons-nous besoin? Pourquoi devrions-nous le gérer au début? N'hésitez pas à partager votre suggestion ou expérience dans le domaine @ ngrx/store!
Je pense que vous devriez lire ces deux articles sur le magasin Ngrx:
- Couches de service angulaires: Redux, RxJs et Ngrx Store - Quand utiliser un magasin et pourquoi?
- Ngrx Store - Un guide d'architecture
Si le premier explique les principaux problèmes résolus par Ngrx Store, il cite également cette déclaration du React How-To "qui semble s’appliquer aussi bien à Flux original, Redux, Ngrx Store ou à toute solution de magasin en général. ":
Vous saurez quand vous aurez besoin de Flux. Si vous n'êtes pas sûr d'en avoir besoin, vous n'en avez pas besoin.
Pour moi, le magasin Ngrx résout plusieurs problèmes. Par exemple, lorsque vous devez gérer des éléments observables et lorsque la responsabilité de certaines données observables est partagée entre différents composants. Dans ce cas, les actions du magasin et du réducteur garantissent que les modifications de données seront toujours effectuées "de la bonne manière".
Il fournit également une solution fiable pour la mise en cache des demandes http. Vous pourrez stocker les demandes et leurs réponses afin de pouvoir vérifier que la demande que vous faites n'a pas encore de réponse stockée.
Le deuxième article traite de la raison pour laquelle de telles solutions apparaissent dans le monde React avec le problème du compteur de messages non lus de Facebook.
Concernant votre solution de stockage de données non visibles dans des services. Cela fonctionne bien lorsque vous traitez avec des données constantes. Mais lorsque plusieurs composants devront mettre à jour ces données, vous rencontrerez probablement des problèmes de détection des modifications et des problèmes de mise à jour inappropriés, que vous pourriez résoudre avec:
- modèle d'observateur avec sujet privé Public observable et fonction suivante
- Ngrx Store
Il existe également une troisième option, avoir des données dans le service et utiliser le service directement en HTML, par exemple *ngFor="let item of userService.users". Ainsi, lorsque vous mettez à jour userService.users dans le service après que l'action d'ajout ou de mise à jour est automatiquement rendue au format HTML, vous n'avez pas besoin d'observables, d'événements ni de magasin.