NGRX Workshop Notes - Introduction

When to use it?

This question was several times and basically you can use the SHARI principle to find out if ngrx or redux is needed for your application or even a specific component inside your app.

In it, we introduce the SHARI principle: any state that needs to be Shared, Hydrated, made Available across routes, Retrieved with a side effect, or is Impacted by other components/effects belongs in the Store.

15:18 PM - 22 Apr 2018

From the docs we get the following:

@ngrx/store (or Redux in general) provides us with a lot of great features and can be used in a lot of use cases. But sometimes this pattern can be an overkill. Implementing it means we get the downside of using Redux (a lot of extra code and complexity) without benefiting of the upsides (predictable state container and unidirectional data flow).

The NgRx core team has come up with a principle called SHARI, that can be used as a rule of thumb on data that needs to be added to the store.

Shared: State that is shared between many components and services
Hydrated: State that needs to be persisted and hydrated across page reloads
Available: State that needs to be available when re-entering routes
Retrieved: State that needs to be retrieved with a side effect, e.g. an HTTP request
Impacted: State that is impacted by other components

Try not to over-engineer your state management layer. Data is often fetched via XHR requests or is being sent over a WebSocket, and therefore is handled on the server side. Always ask yourself when and why to put some data in a client side store and keep alternatives in mind. For example, use routes to reflect applied filters on a list or use a BehaviorSubject in a service if you need to store some simple data, such as settings. Mike Ryan gave a very good talk on this topic: You might not need NgRx

Also, the following question was asked:

Once you add ngrx to an application, is it a bad practice to use a service with BehaviorSubject to communicate between components? Example. Having a modal with a form that uses a stepper. Should the modal use NGRX because the whole app is using ngrx.

The response from Mike was:

No, you do not have to use ngrx for all your states.

We have this term called SHARI principle and essentially the only state that goes into the ngrx store is a truly global state, state that is shared between your components, state that needs to be rehydrated when the application boots up or is impacted by actions of other features.

If the state doesn't match that rubric, then it is totally fine to use a simple state storage mechanism for it as a service with a Behavior Subject.

Another related comment by Alex:

One of the things I remember myself when I started using ngrx, I tried to push anything ngrx mostly because I wanted the dev tools to the time travel and I think some of the features that are exciting and helpful can misguide you. The moment of realization for me is not to push everything possible into it, at that time we were learning, as the pattern was evolving, now is kind of known what are the best practices.

Some of the things I don't put in the store are Form Controls (since it is already a reactive state), the local state within components (even if it interacts with the network), some of the lifecycle state for a component. Basically, the first thing I asked myself is how shareable is the state, how much does the application needs to know about this.

Here is a link to a re-usable service that uses BehaviorSubject and can be used for simpler communication cases

Here is a library by Dan Wahlin that can help for simple state management:

DanWahlin / Observable-Store

Observable Store provides a simple way to manage state in Angular, React, Vue.js and other front-end applications.

Observable Store - State Management for Front-End Applications (Angular, React, Vue.js, or any other)

Observable Store is a front-end state management library that provides a simple yet powerful way to manage state in front-end applications. Front-end state management has become so complex that many of us spend more hours working on the state management code than on the rest of the application. Observable Store has one overall goal - "keep it simple".

The goal of observable store is to provide a small, simple, and consistent way to manage state in any front-end application (Angular, React, Vue.js or any other) while achieving many of the key goals offered by more complex state management solutions. While many front-end frameworks/libraries provide state management functionality, many can be overly complex and are only useable with the target framework/library. Observable Store is simple and can be used with any front-end JavaScript codebase.