Building Angular NgRx based libraries

Discord discussion:

shaileshinpune — 20/04/2021 If we have an angular library of common reusable components that has its own ngrx store and each of its component uses its own component store. Can we have a bridge to these store from the consumer app which uses some of its components and would like to access state from common store of the library as well as from components that it uses? derekkite — 20/04/2021 is your ngrx store implementation feature state? shaileshinpune — 23/04/2021 Yes as I said it features state that’s what stores are for? derekkite — 23/04/2021 When the feature libraries are loaded, the module would initialize StoreModule.forFeature so it becomes part of the state. The actions will be seen everywhere. The selectors from the app to the feature state would be challenging. From the feature to the app would work as normal, with some error checking to make sure the other state exists. shaileshinpune — 24/04/2021 So probably its better to not use a common state at all and make components as independent as possible n use component store for each of them? If I do that components when included in consumer app will they be able to consume app state oob? Like what if they have to react to actions ? Tim Deschryver — 24/04/2021 To be honest, that's a decision that we can't make for you because it depends... We can refer you to our docs to see the advantages of each package https://ngrx.io/guide/component-store/comparison derekkite — 24/04/2021 @shaileshinpune those isn't really a store issue, but a library structure issue. I like to start with the whole purpose of state, rendering a component. The component needs two things from the store implementation; the selectors that expose the data as required, and the actions required to tell the store to do things. If everything is split up into libraries, you would have a library dependency tree. Here is an example. Component that displays information from GPS location. Call the library MapComponent. It depends on GpsDataStore library which exposes selectors and actions. It also depends on ContactsDataStore library for customer locations. The component wants to know what customers were visited. Actions and selectors to do that are exposed by this library. It depends on JobsDataStore library. What jobs and jobsites were visited. Actions and selectors. Each of those libraries has it's own component libraries for editing and viewing jobs and contacts. The MapComponent may need some components from those libraries.

As you can see, the Store and Ngrx part is making sure the data is loaded in the state. The complexity is the dependency tree between the many parts which are set up as libraries. So from a conceptual point of view there isn't app state. There are component library dependencies. The component library has access to actions and selectors. The implementation details from the store point of view are simply making sure that those selectors have state to select for, and effects and reducers to listen for the actions.