feat: add withEventsTracking (#231)

[wolfmanfx]

Summary

Adds withEventsTracking() as a DevTools feature and integrates it with withDevtools() so Redux DevTools shows meaningful event names from @ngrx/signals/events instead of the generic "Store Update".

Context

Debugging SignalStore reducers triggered by @ngrx/signals/events was 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

• Introduce withEventsTracking() as a DevTools feature:
  • Implemented via createDevtoolsFeature({ eventsTracking: true }).
• Extend DevTools internal options:
  • DevtoolsOptions gains eventsTracking?: boolean.
  • DevtoolsInnerOptions gains eventsTracking: boolean.
• Integrate with withDevtools():
  • When eventsTracking is enabled, subscribe to Events.on() via an internal rxMethod.
  • Push event type values into currentActionNames to be used as the next DevTools action label.
• Keep existing DevTools behavior unchanged when the feature is not enabled.

Usage

export const BookStore = signalStore(
  withDevtools('book-store', withEventsTracking()),
  withState({ /* state */ }),
  withReducer(
    on(bookEvents.loadBooks, /* reducer */),
    on(bookEvents.bookSelected, /* reducer */),
  )
);

Compatibility

• Angular 20+: Supported on main.
• Backportable: Compatible with Angular 15–19 (no Angular 20+ only APIs used).
• Breaking changes: None (opt‑in feature).

Testing

• DevTools timeline now displays event names when using withEventsTracking().
• No behavior changes for non‑opt‑in users.

Suggested commands:

pnpm install
pnpm -w lint
pnpm -w test
pnpm -w build

Documentation

• Add a short section under DevTools docs showing withEventsTracking() usage and expectations.

Checklist

• Conventional Commit title with monorepo scope
• Public API unchanged for existing consumers; feature is opt‑in
• No unintended exports
• TypeScript strictness preserved

Linked Issues

Closes #231

[IlyaBielov]

When will it be done?

[rainerhahnekamp]

@IlyaBielov soon. It will be released with the fix for #242

[rainerhahnekamp]

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:

1. Default case
   A simple reducer where we verify that the action name is correctly shown in the devtools.

2. 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.

3. 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 an updateState.
   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.

[rainerhahnekamp]

I think we require here, the glitch free tracker as well, right?

So I would kind of merge here glitch-free tracker.