-
Couldn't load subscription status.
- Fork 44
feat: add withEventsTracking (#231) #233
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?
Conversation
|
When will it be done? |
|
@IlyaBielov soon. It will be released with the fix for #242 |
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.
All good — the implementation looks fine to me, I don’t see anything that needs to change except for adding the tests.
I’m thinking of three basic ones:
-
Default case
A simple reducer where we verify that the action name is correctly shown in the devtools. -
Multiple stores reacting to the same event
Two stores subscribe to the same event, meaning both reducers patch their state.
Since glitch-free tracking is enabled by default, the test should ensure that the devtools display the same action twice - once per store, each with its respective state change. -
Glitch-free tracking within a single store
A SignalStore has a method that dispatches an event handled by its own reducer.
Immediately after dispatching the event, it performs anupdateState.
The test should verify that the devtools record these as two distinct actions.
Of course, feel free to come up with additional tests if you see other relevant cases.
It would also be great if we could keep these tests in a separate file.
| * the default "Store Update". | ||
| */ | ||
| export function withEventsTracking() { | ||
| return createDevtoolsFeature({ |
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 think we require here, the glitch free tracker as well, right?
So I would kind of merge here glitch-free tracker.
Summary
Adds
withEventsTracking()as a DevTools feature and integrates it withwithDevtools()so Redux DevTools shows meaningful event names from@ngrx/signals/eventsinstead of the generic "Store Update".Context
Debugging SignalStore reducers triggered by
@ngrx/signals/eventswas difficult because DevTools labeled all updates as "Store Update". This resolves the request in #231 by inferring event names and surfacing them to DevTools.Reference: #231 (comment)
Changes
withEventsTracking()as a DevTools feature:createDevtoolsFeature({ eventsTracking: true }).DevtoolsOptionsgainseventsTracking?: boolean.DevtoolsInnerOptionsgainseventsTracking: boolean.withDevtools():eventsTrackingis enabled, subscribe toEvents.on()via an internalrxMethod.typevalues intocurrentActionNamesto be used as the next DevTools action label.Usage
Compatibility
main.Testing
withEventsTracking().Suggested commands:
pnpm install pnpm -w lint pnpm -w test pnpm -w buildDocumentation
withEventsTracking()usage and expectations.Checklist
Linked Issues
Closes #231