-
-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(store): add possibility to dispatch Signal<Action> #4600
base: main
Are you sure you want to change the base?
feat(store): add possibility to dispatch Signal<Action> #4600
Conversation
✅ Deploy Preview for ngrx-io ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify site configuration. |
f70110f
to
dc049ef
Compare
A type of Signal<Action> can be passed to dispatch: ```typescript class BookComponent { bookId = input.required<number>(); bookAction = computed(() => loadBook({id: this.bookId()})); store = inject(Store); constructor() { this.store.dispatch(this.bookAction); } } ``` The benefit is that users no longer need to use an effect to track the Signal. The Store handles this internally. If `dispatch` receives a `Signal` it returns an `EffectRef`, allowing manual destruction. By default, the injection context of the caller is used. If the call happens outside an injection context, the Store will use its own injection context, which is usually the root injector. It is also possible to provide a custom injector as the second parameter: ```typescript this.store.dispatch(this.bookAction, {injector: this.injector}); ```
dc049ef
to
58da96d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice!
I left some comments for the syntax in the docs.
Co-authored-by: Tim Deschryver <[email protected]>
Co-authored-by: Tim Deschryver <[email protected]>
Co-authored-by: Tim Deschryver <[email protected]>
Co-authored-by: Tim Deschryver <[email protected]>
Thanks @timdeschryver, I've applied all your changes |
`dispatch` now accepts a function that returns an `Action`. Providing a `Signal<Action>` will still be possible (`Signal` is also a function). I had to rename the type `FunctionIsNotAllowed` to `NoActionCreator`. Previously, `FunctionIsNotAllowed` was used to prevent passing functions to `dispatch`, but the primary intent was to forbid `ActionCreator`. ```typescript store.dispatch(loadBook); // 👎 store.dispatch(loadBook({id: 1})); // 👍 ``` As the name says, `NoActionCreator` now explicitly forbids only `ActionCreator`. Functions are fine. Otherwise, the new feature would not be possible.
I had to rename the type Previously, store.dispatch(loadBook); // 👎
store.dispatch(loadBook({id: 1})); // 👍 As the name says, |
A type of Signal can be passed to dispatch:
The benefit is that users no longer need to use an effect to track the Signal. The Store handles this internally.
If
dispatch
receives aSignal
it returns anEffectRef
, allowing manual destruction.By default, the injection context of the caller is used. If the call happens outside an injection context, the Store will use its own injection context, which is usually the root injector.
It is also possible to provide a custom injector as the second parameter:
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
What is the current behavior?
Users need to manually track Signals via
effect
Closes #4537
What is the new behavior?
Does this PR introduce a breaking change?