So after using ngrx for some time and trying to combine both the DRY principle with good action hygiene i came to a conclusion that something feels off. My most notable use case is storing a grid state. We have around 20 grids in our app and each one of them has the same requirements - sorting, filtering, etc...
To those saying why keep it in store - the state of the grid is persisted between routes do it does answer SHARI.
The grid "store" has many actions, reducers and effects while the only difference from one grid to another is the context.
Now the problems start to arise...
- I am definitely not going to copy paste the whole grid logic 20 times.
- I cant use one state as each grid has its own "instance".
- I thought maybe to create a grids entity but it has a few problems:
- It is not really an entity as the number of grids is known at design time and i will never add/remove grids at runtime.
- It feels awkward to have all the app grids (even when the state should be lazy loaded) in one HUGE entity.
- What actions will it have? An action called
GridSortButtonClickedis OK although each grid is from another context? Is it really good action hygiene?
In any case the grid can be accessed from different parts (for example i want to reset the filters on the grid in some cases from another flow) so that means the grid needs to know each accessing namespace.
The point is it seems good action hygiene is good for the TODO or AUTHORS and BOOKS example apps - but how can it still work for large apps? Is it worth it to use the good action hygiene in exchange for the DRY principle and copy paste everything? What happens when a change needs to be made for all grids in the app? I really got lost when i tried applying ngrx "best practices" in large apps as it felt as if i need to copy paste A LOT of code.