Follow

Follow
NgRx Workshop: Part 1- Introduction Introduction

NgRx Workshop: Part 1- Introduction Introduction

Alfredo Perez's photo
Alfredo Perez
·Apr 2, 2020·

4 min read

These are the comprehensive notes I diligently compiled while participating in the insightful NgRx workshop, which took place during the renowned ng-conf event. This workshop was specifically designed to provide an in-depth understanding of the NgRx framework, its best practices, and the latest updates in the Angular community.


When to use it?

This question was asked 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.

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

{% link dev.to/alfredoperez/angular-service-to-hand.. %}

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

{% github DanWahlin/Observable-Store%}

Resources

 
Share this