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
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
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