@ngrx/signals: Extension Point stateChange

[rainerhahnekamp]

Which @ngrx/* package(s) are relevant/related to the feature request?

signals

Information

It would be nice for the devtools community plugin to get an extension point which notifies about state changes:

Approach 1: Hooks

The existing hooks get a new callback like onChange or onStateChange. DevTools could register then, and we're done.

Approach 2: Standalone Function

Or we do it via a standalone method like watchStateChange(state: STATE_SIGNAL, callbackFn: (value: unknown) => void)

Describe any alternatives/workarounds you're currently using

At the moment, there are some workarounds which only work with very strict constraints. Like using a modified patchState function.

I would be willing to submit a PR to fix this issue

• Yes
• No

[markostanimirovic]

This is already possible by using the getState function within the effect:

import { getState } from '@ngrx/signals';

withHooks({
  onInit(store) {
    effect(() => {
      const state = getState(store);
      console.log('state changed', state);  // state will be logged on changes
    });
  }
})

[rainerhahnekamp]

Thanks @markostanimirovic. Just to clarify what I mean:

    const Store = signalStore(
      withState({ name: 'Coffee in Italy', price: 0.99 }),
      withHooks({
        onInit(store) {
          effect(() => console.log(getState(store)));
        },
      })
    );
    const store = new Store();

    patchState(store, { name: 'Coffee in Austria' });
    patchState(store, { price: 3.4 });

Right now, the devtools show one action with the expensive Austrian coffee. What I mean is to have two different actions.

So in case that Angular (angular/angular#53703) doesn't provide it natively, we need support from @ngrx/signals itself.

@mikezks If I remember correctly you required such a feature, right?

The other option is that DevTools don't show glitchy actions, and if somebody complains, we can continue this discussion here.

[jits]

It may be worth noting also that getState doesn't return the values of computed properties (which could matter for the community devtools plugin).

[rainerhahnekamp]

@jits I would be careful showing computed in the Devtools.

In the end, they work like the selectors in NgRx, and we shouldn't forget, that they are also lazyly evaluated.

So I'm not sure if it is a good idea to - using the NgRx selector terminology - make them hot, although they aren't used in the application itself.

[jits]

@rainerhahnekamp — that makes sense. It would be useful to add something about this in your coming "frequently asked questions" work — something along the lines of "as a reminder, computed signals are lazily evaluated" (if it makes sense to you to add it).

I do think though that we need a way to show visibility on computed values, as they still represent part of the overall state and can be important for debugging purposes. I don't have a great idea/solution at the moment; hopefully the future work to surface signals in the Angular DevTools will solve this somehow 😄

[rainerhahnekamp]

Yeah, with computed, it is a two-edged sword. It could be the case that computed have side-effects. That's not really recommended but it is technically possible. So you don't want to trigger them, just because devtools are enabled.