Why does ngrx/store example app use multiple stores? (how to design store)

Question

I am trying to make a rather big, scalable application and I was told it is best practice to have one single store storing the current global state (including both transient/deleted-on-reload and session-persistent data) of the whole application, even if it is separated into multiple modules.

Now I was wondering why the example app of the ngrx/store which you can find on the ngrx/store-website uses multiple stores; each reducer has an own piece of code like this:

export interface State {
  ids: string[];
  entities: { [id: string]: Book };
  selectedBookId: string | null;
};

export const initialState: State = {
  ids: [],
  entities: {},
  selectedBookId: null,
};

So why does the official guide not use a single store as recommended by most people? Or is it considered as a single store as long as all reducers belong to one module? If not, how do I implement one single, central store? My idea would be to use a Store generic and put their variations into a table. The other option would be to have one single JS-object whose properties you update with reducer-actions. Either way you have to have some structure in the table or Object. Are there any best practices for this? Do you know a better example-app?

Answer 1

The example app is using a single store. State in this case is the interface for a reducer. You can have many reducers in one store.

It's considered best practise to use a single store. A single store should be sufficient for almost all small and medium sized apps.

There is a very good example of the Angular Tour of Heroes application recreated with NGRX Store. You can find it here: http://bodiddlie.github.io/ng-2-toh-with-ngrx-suite/