-
-
Notifications
You must be signed in to change notification settings - Fork 2k
feat(signals): provide support for scoped events #4997
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
base: main
Are you sure you want to change the base?
feat(signals): provide support for scoped events #4997
Conversation
✅ Deploy Preview for ngrx-io canceled.
|
✅ Deploy Preview for ngrx-site-v19 ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
rainerhahnekamp
left a comment
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.
Will you provide the updated documentation in a separate PR?
|
@rainerhahnekamp Yes, I'll add a new section 'Scoped Events' without changing existing content from the Events page because the previous behavior remained the same. |
| mapToScope, | ||
| toScope, | ||
| } from './event-scope'; | ||
| export { Events, ReducerEvents } from './events-service'; |
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.
That is important for the event tracker in the toolkit. 👍
rainerhahnekamp
left a comment
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.
LGTM 👍
timdeschryver
left a comment
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.
Lovely! 🤩
| * \@Component({ | ||
| * \/* ... *\/ | ||
| * providers: [provideDispatcher()], | ||
| * }) |
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.
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.
| * ); | ||
| * ``` | ||
| */ | ||
| export function toScope(scope: EventScope): EventScopeConfig { |
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.
An open question about the naming of this function, sorry I should've mentioned this in the RFC.
What about renaming it to withScope, I think this makes the intent easier to read.
[loadSuccess(), withScope('global')]
// or
[loadSuccess(), scopedTo('global')]I'm also fine with toScope though.
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.
I'd keep the toScope name for consistency with mapToScope, but also to distinguish it from SignalStore features that have the with prefix.
In general, this helper is not required (we can directly return [loadedSuccess(), { scope: 'global' }]), but I added it for a bit better DX - to avoid typos and enable autocompletion in IDEs for the scope name. Anyway, mapToScope will be the common way to change the default event scope in the effect, while toScope can be used if we want to have more granular control and have different scopes for success and error events, which would be a rare case.


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?
Closes #4776
What is the new behavior?
Does this PR introduce a breaking change?