Angular 6 - Why use @ngrx/store rather than service injection

Question

I am recently learning Angular 6 with @ngrx/store while one of the tutorial is to use @ngrx/store for state management, however I don\'t understand the benefit of us

Answer 1

If the data in your app is used in multiple components, then some kind of service to share the data is required. There are many ways to do this.

A moderately complex app will eventually look like a front end back end structure, with the data handling done in services, exposing the data via observables to the components.

At one point you will need to write some kind of api to your data services, how to get data in and out, queries, etc. Lots of rules like immutability of the data, and well defined single paths to modify the data. Not unlike the server backend, but much quicker and responsive than the api calls.

Your api will end up looking like one of the many state management libraries that already exist. They exist to solve difficult problems. You may not need them if your app is simple.

Answer 2

There is also a 3rd option, having data in service and using service directly in html, for instance *ngFor="let item of userService.users". So when you update userService.users in service after add or update action is automatically rendered in html, no need for any observables or events or store.

Answer 3

I think you should read those two posts about Ngrx store:

• Angular Service Layers: Redux, RxJs and Ngrx Store - When to Use a Store And Why?
• Ngrx Store - An Architecture Guide

If the first one explains the main issues solved by Ngrx Store, it also quote this statement from the React How-To "that seems to apply equally to original Flux, Redux, Ngrx Store or any store solution in general":

You’ll know when you need Flux. If you aren’t sure if you need it, you don’t need it.

To me Ngrx store solves multiple issues. For example when you have to deal with observables and when responsability for some observable data is shared between different components. In this case store actions and reducer ensure that data modifications will always be performed "the right way".

It also provides a reliable solution for http requests caching. You will be able to store the requests and their responses, so that you could verify that the request you're making has not a stored response yet.

The second post is about what made such solutions appear in the React world with Facebook's unread message counter issue.

Concerning your solution of storing non-obvervable data in services. It works fine when you're dealing with constant data. But when several components will have to update this data you will probably encounter change detection issues and improper update issues, that you could solve with:

• observer pattern with private Subject public Observable and next function
• Ngrx Store