Did the new NGRX update add Object.freeze calls to the signalstore?

[PhilippMDoerner]

I just recently updated my application to Angular 19 and I heavily use signalstore.
For some reason at one point I also used signalstore in order to store which route the user last visited:

export const NavigationStore = signalStore(
  withState(initialState),
  withComputed((state) => {
    const router = inject(Router);
    const currentRoute$ = router.events.pipe(
      filter((event) => event instanceof NavigationEnd),
      map(() => router.routerState.snapshot.root),
      map((route) => {
        while (route.firstChild) {
          route = route.firstChild;
        }
        return route;
      }),
    );

    return {
      currentRoute: toSignal(currentRoute$),
      priorUrl: computed(() => state.history().priorRoute?.url),
      currentUrl: computed(() => state.history().currentRoute?.url),
    };
  }),
  withHooks((store) => {
    log('NavigationStore', store);
    const router = inject(Router);
    return {
      onInit: () => {
        router.events
          .pipe(
            filter((event) => event instanceof RoutesRecognized),
            pairwise(),
            takeUntilDestroyed(),
          )
          .subscribe(([priorRoute, currentRoute]) => {
            patchState(store, {
              history: {
                currentRoute,
                priorRoute,
              },
            });
          });
      },
    };
  }),
);

With Angular 19 and the latest NGRX store this will break routing, because the signal-store now freezes the ActivatedRouteSnapshot inside the router-event, which it did not do before.

The reason this breaks routing is because the angular router will update the data property on an object that has now been frozen.

I'm opening this discussion first in order to ascertain whether that was indeed the change in signalstore.
And second in order to figure out how I could've avoided stumbling into this issue in the first place (or prevent others from stumbling into it).
Because accessing something from the router in a store does not seem like that rare a usecase.
For the most part my current learning is to avoid ever touching anything from routing inside of a store, though I'm not sure what else.

[timdeschryver]

Hello, yes v19 introduced "freezing", https://ngrx.io/guide/migration/v19#throw-error-in-dev-mode-on-state-mutation.
We're currently discussing it, for now the recommendation is to add the state within withProps, e.g. #4636

[PhilippMDoerner]

What surprises me the most is that it also froze the ActivatedRouteSnapshot and its parent from the router.event.

What would be the syntax in order to avoid for this to happen?

[rainerhahnekamp]

Philipp, yes, the freezing is very likely the problem. As soon you put a value into a Signal and start mutating that one, this is not good. The Signal will "change its value" but will not notify any of it dependencies because it is not aware of it.

As Tim said, withProps is the place for mutable properties.

Since you want to store the history of the routes, you might not need to put the ActivatedRoute into it, but just take the parts you need and put them into a new object. That would then also work for withState.

[PhilippMDoerner]

The thing here is that I and my code do not mutate that signal or any of the data. The angular router itself does. That's why I didn't anticipate this happening at all.

Regardless of what my code looks like, the second a snapshot gets into the Signalstore, any router.navigateByUrl call will break and raise an exception.

I agree with your proposal though that I likely could've prevented the problem by storing selected parts of the snapshot/Router-event instead of the entire thing. That just didn't come to mind because storing the full event itself when you might need to use it in various different contexts seemed like the more obvious solution.

[PhilippMDoerner]

Thank you for the recommendation for withProps @timdeschryver , I'll keep that in mind in the future for interactions with observables from angular itself.

This was the solution I arrived at:

import { computed, inject } from '@angular/core';
import { toSignal } from '@angular/core/rxjs-interop';
import { NavigationEnd, Router, RoutesRecognized } from '@angular/router';
import { signalStore, withComputed, withProps } from '@ngrx/signals';
import { filter, map, pairwise } from 'rxjs';

export const NavigationStore = signalStore(
  withProps(() => {
    const router = inject(Router);
    return {
      _currentRoute$: router.events.pipe(
        filter((event) => event instanceof NavigationEnd),
        map(() => router.routerState.snapshot.root),
        map((route) => {
          while (route.firstChild) {
            route = route.firstChild;
          }
          return route;
        }),
      ),
      _history$: router.events.pipe(
        filter((event) => event instanceof RoutesRecognized),
        map((event) => event.url),
        pairwise(),
        map(([priorRoute, currentRoute]) => ({
          currentRoute: currentRoute,
          priorRoute: priorRoute,
        })),
      ),
    };
  }),
  withComputed((state) => {
    const history = toSignal(state._history$);
    return {
      currentRoute: toSignal(state._currentRoute$),
      priorUrl: computed(() => history()?.priorRoute),
      currentUrl: computed(() => history()?.currentRoute),
    };
  }),
);

Some further testing confirmed that this version won't block the mutations done inside the Angular router.