Introduction

This module is going to primarily be about using the @ngrx/component-store package as an advanced approach to state management in your Angular applications, and why we would even want to use something like that in the first place.

Since state management is such a huge topic, especially when we start getting to the more advanced side of things, it might seem a little arbitrary to point to one library and be like:

This is what we are going to learn

Ultimately, it’s worth baring in mind that there are a lot of different options, and the primary reason we are using this one is because it is what I like. I have to pick something to teach, so naturally I am going to pick the approach I think is best suited.

However, attempting to be as non-biased as I possibly can be, I do think @ngrx/component-store is one of the best libraries to choose for this role. The reasons I would give for this are:

• It is widely popular among expert Angular developers
• It is mostly not all that different to the standard service with a subject approach, so it is reasonably easy to learn
• It is generally used for local component state, so it doesn’t require some application wide strategy to implement
• It helps you to code reactively
• It can be used for very simple applications, but also scales quite well. In most cases, you could solely use @ngrx/component-store for all of your state management in the application. But, if you were getting into even more complex territory you can also easily add something like @ngrx/store for global state management, whilst still using @ngrx/component-store for local state management.

The Basic Idea

Over the next few lessons we are going to build up a conceptual model of what NgRx Component Store is all about. But, let’s get some sort of high level idea of the concept right now.

The general idea is that our components may have an associated Component Store that is provided to it. The Component Store will handle storing all of the state for that component, and we will be able to access parts of that state as an observable stream. If we need to update some part of the state, we would also use the Component Store to do that.

It is a lot like the service with a subject approach we have seen and used a lot - if that service was provided to just one single component rather than the entire application.

Let’s say we have a smart component for an account management page that has multiple pieces of state to deal with. Maybe we have an observable to determine whether a modal that displays help information is open, another observable that contains information about the currently logged in user, and another observable that contains the state of a form for updating the users details (i.e. has the form been submitted?).

We could store all of that state information directly in the component. Or, to reduce the complexity of that component, we could create a separate service to handle all of that state - the component would then communicate with the service for its state. Or, we could create that separate service and also extend ComponentStore to add some super powers to that service.

Why would you use it?