State Management Libraries

The state management approach we have looked at is something that can scale well — I think it also adheres to the idea of declarative and reactive code more closely than many other state management libraries.

There is no specific reasons that you have to use a state management library — but certain libraries might provide you with certain conveniences or use a particular style that you like. Perhaps you join a team where state is handled using a state management library.

It is not a goal of this course to cover how to integrate various state management libraries, but I do want to give you an idea of some of the popular options out there that you might come across and what their general philosophy is.

StateAdapt

StateAdapt is a very new state management library, which does make it risky to use. However, I wanted to give it a quick special mention because I think it is the state management library that deals with the idea of coding reactive/declaratively the best.

In general, the philosophy is very much the same as the approach we are using — that is due in large part to the fact that I was heavily inspired by it when deciding on the approach we are using in this course.

The API to use it is perhaps a bit more confronting than what we have covered, but it offers a bunch of extra features.

Popular Libraries

For the rest of this lesson, I am going to briefly cover some of the popular state management libraries for Angular. I will start with the ones I use and know the most about, because I have experience with them and can give a little more insight into them, but don’t take this as meaning that these approaches are necessarily the best.

NgRx Component Store

If you are not new to Angular then maybe you have heard of NgRx already. When people refer to NgRx they generally mean NgRx Store specifically, which has quite a reputation for being complex. However, NgRx is a collection of libraries, and NgRx Store is just one of those.

Whilst NgRx Store has a reputation for being complex, NgRx Component Store is quite the opposite. It is an extremely lightweight state management solution that is primarily intended to manage local state for components, but it can also be used as a simple global store for shared state.

Before I switched to this new state management approach, NgRx Component Store was pretty much all I used for a long time — I like it because it is simple, but it is also flexible and powerful enough for pretty much every situation. It also integrates very well with a reactive/declarative approach to building Angular applications.

The reason I switched away from it is just because I think the RxJS/Signals approach we have been talking about is a bit more declarative and a bit easier to use. This is very heavily preference based though — you might find you like the NgRx approach more.

In the lesson on local state, we already covered the idea of creating a service and providing it to just one component, e.g:

@Component({
  // snip...
  providers: [ChecklistItemStore],
})

This is the general idea behind Component Store as well — we will create a service (we will call it a “store”) and we provide that to a single component. However, the service we create with Component Store will be a little special:

export interface MoviesState {
  movies: Movie[];
}

@Injectable()
export class MoviesStore extends ComponentStore<MoviesState> {

  constructor() {
    super({movies:[]});
  }

  readonly movies$: Observable<Movie[]> = this.select(state => state.movies);
}