Reputation: 429
Beginning to learn angular, but unsure how to architect the structure with ngrx.
In simply term I have a service that has two array in it, and methods to manipulate those array in specific ways. I created the service, cause multiple component need that logic of manipulating the array. Some of them will use the same state of one of those array, some will have a different state.
Different component will access this service, make change to array and get array back to render. However after doing research online, it seems common practice is to keep service stateless. And then I came across ngrx store.
So I am thinking I can put that arrays in a main store instead of it being in the service, so it becomes:
Component will use the service, manipulate the array, service will trigger an action, then the store will notify the components of the array change
However looking at the diagram in ngrx https://ngrx.io/generated/images/guide/store/state-management-lifecycle.png. There would be a arrow between component and services, and that seem like it will create a mess when the app get bigger.
So how should I approach this? Am I misunderstanding something here? Maybe the service should be a component instead (but reading https://angular.io/guide/styleguide#delegate-complex-component-logic-to-services, it does seem like I am doing the correct thing, moving logic out of component to service, making component simple).
Any advice is greatly appreciated
Upvotes: 1
Views: 2094
Reputation: 6290
A few tips to try to help you understand NgRx and design your best fit architecture :
You should have only one single source of truth. It means keep only original data into state. It's important here to differenciate multiple views of the same data, or mutation of original data.
State is mutated into reducer functions via Actions. These pure functions (reducer) transforms state A to state B. For example : Add a new item into your array.
Selectors are dedicated to select (extract) slice of data from the store. You can think about databases (state) and SQL Select (selectors).
It means you can retrieve a subset of data, filtered, sorted... of your array for a need of a specific component. But also a combination of multiple slice of state, returned as a new type.
With NgRx, it's sometime true that services lose some of their strategic role. For my point of view, and my experience, services are mainly used for external requests to api backend.
Transformation logic is in reducer, and should be kept simple. Extraction logic (view) is in selectors.
To keep this organization clear, and maintable, prefer sepearate files for instance :
You should also differenciate 2 types of components :
dump components : only UI
component, without any logic, no call or dependency to NgRx, state, service... Just @Input
, and @Output
with simple data.
container or smart components: think of them as traffic control tower. They have dependencies to NgRx, they can dispatch actions, and subscribe to state updates (via selectors). They organize link between data retrieved from selectors and dump components.
Upvotes: 6