- 11Extract Implementation Details of ngrx from an Angular Application with the Facade Pattern7m 4s
Extract Implementation Details of ngrx from an Angular Application with the Facade Pattern
Share this video with your friends
Extracting away the implementation details of ngrx from your components using the facade pattern creates some interesting possibilities in terms of iteratively migrating an application to ngrx. By decoupling your components from ngrx completely, this also makes testing and collaboration a lot easier. In this lesson, we will finalize our application by creating a facade to sit in between our component and ngrx and hide all of the ngrx implementation details away from our component. This has an added benefit of reducing the number of pieces that we need to export in our state module's barrel roll by reducing our dependency down to a single facade.
I really enjoyed watching the course.
I have a similar application that I'm experimenting with two lazily loaded modules. I can compare that to Customers and Projects. They are loaded separately by the application through it's own routes. As I understand, when a lazily loaded angular module is loaded and if it has a store in it, the store will be re-created. So the data will be lost.
How do I design the angular application with an ngrx store that have two modules like Customers and Projects which are loaded lazily but at the same time the store will live until the application is shut down.
I posted the question in stack overflow also at https://stackoverflow.com/questions/56100953/how-to-make-feature-module-state-cached-globally-from-many-lazy-loading-modules
I appreciate your feedback.
This is a good question! Two points that I want to make here...
- I always isolate application state (NgRx) into its own module and using an NX workspace, I can consume it across N number of applications. Basically, I never split state across modules but instead consolidate it into a single module that can be shared across features. This keeps your application layer very small and concise.
- If you use
Store.forFeatureinstead ofStore.forRoot, your store is not overwritten as you add in new features.
Hi Lucas. I really like the facade approach to ngrx. I'm curious what your approach is to "good action hygiene". Would your facade have a specific method for each component that needs to dispatch the "same" action? Would the method take a "source" string for the originator of the dispatch? Feels like having a .dispatch() method would defeat the purpose of the facade. Thanks.
Hi Jim - I believe that this approach of component specific methods for dispatching the same action would product negligible (if any) benefit. Components should be extremely thin in that they consume just enough data for the templates to render and convert user events into actions. As a result, the surface area for a bug to be introduced by a component is significantly reduced. I have found in practice that I only care about what is in the action and more importantly where it is going. Hope that helps!
Lucus, thanks very much for your reply. I concur with your opinion and feel more comfortable now that you have validated that facade design!
Thank you Lukas. I currently use Store.forFeature in every feature module. I have also only one application which I hope will work on different devices - uses bootstrap to be reactive. Let me see how the application will perform and then move to a global module.