best practice regarding composed state with signal store #4578
Replies: 2 comments
-
probably solved by https://github.com/markostanimirovic/ngrx-signals-events-prototype |
Beta Was this translation helpful? Give feedback.
0 replies
-
If you find eventing a good fit, you'll soon have a solution. The other option for inter-store communication is that your stores just inject their dependent stores. That's how did until now. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I am currently abusing (?) custom store features to compose the state of application libraries.
I am doing it mainly to build some logical domains inside the store and to reduce the cognitive load to be endured while parsing a store definition file (300 - 500 lines works for me).
-> e.g. my pet shop library would have custom store features for, let's say, animals in stock, feed in storage and such
In ngrx store i would have different reducers with their state and selectors accessing multiple of those states. Now i am using the signal store as the layer to provides signals derived from feature stores it uses.
This seems bad to me, as it violates how i understand custom store features were meant to be used: My custom feature stores make (nearly) no sense without a specific "parent" signal store.
What can i do to make it better?
Beta Was this translation helpful? Give feedback.
All reactions