freeze state in signalState

[rainerhahnekamp]

It is currently possible to run mutable changes via the $update function. Those mutable changes do not throw any error, and effects tracking that part of the state are also not executed. The tests are located in the "immutability" tests suite of signal-state.spec.ts.

This change applies Object.freeze to the state, causing an error on mutable changes.

The implementation is an almost identical copy of freeze in NgRx.

Other than that,

• move the tests to the test directory, following the existing conventions.
• add withEffect as a test utility method to simplify the tests of effects.

[markostanimirovic]

we should perform deepFreeze only in dev mode for better performance

[rainerhahnekamp]

Still working on that

[markostanimirovic]

test1.ts and test2.ts files contain "type tests 😅", to make sure that typing works fine after refactoring. When we move this lib to the NgRx repo, they will be converted into real type tests. For now, they contain a few commented lines that use selectSignal so feel free to revert this change.

[rainerhahnekamp]

done. I've left testEffects there as it is more a testing file and not a test

[rainerhahnekamp]

Some comments from my latest push:

• $update has DeepReadonly as input which also comes up with a ReadableArray. I think that this improves the DX when immutability is a requirement.
• I was not aware that Object.freeze is never applied during prod mode. For application types, where performance is not a big topic, that would be an attractive option. Maybe we can create a GitHub issue once SignalStore is in beta. Same is true for ngrx/store.
• The unit tests should that I can update the mutate the state as well and the effects are still firing correctly. Is there actually any difference between an immutable and mutable change? Looks like the equal checker works for both.

[markostanimirovic]

Have you tried to run the playground app? It seems that the signalStore typing is broken. 👀

If you agree, we can keep only the deepFreeze related changes in this PR and consider introducing DeepReadonly and other typing changes separately.

Regarding the { immutabilityCheck: boolean } option in the signalState function, I don't see the use-case when it should be set to false because signalState (and signalStore) support only immutable updates. Therefore, I suggest keeping the same signature as before (without options argument) and calling deepFreeze in dev mode:

if (isDevMode()) {
  deepFreeze(state);
}

---

Btw, @ngrx/store provides the ability to turn off the state immutability check, but the main reason for that was to ensure backward compatibility when runtime checks were introduced.

[rainerhahnekamp]

Yeah, you're right. Let's get that freeze feature in and discuss the rest in a separate PR.