SignalStore: RFC: Reverting `Object.freeze` Protection in SignalStore

[rainerhahnekamp]

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

signals

Information

In v19, we introduced a protection mechanism against mutable changes in the SignalStore. This mechanism recursively applied Object.freeze to the state object.

Since its introduction, we’ve received numerous issues and reports from the community:

1. Unintentional Mutations: Many users were already mutating their state without realizing it.
2. Incompatibility: Some users used types that Object.freeze was unable to process, causing runtime errors.

The SignalStore builds on top of Angular’s Signal type, which itself does not enforce immutability through an internal mechanism like Object.freeze. This means, when developers switch to the SignalStore, they encounter a different behavior.

In certain edge cases, mutable changes within Signals are necessary to achieve specific outcomes. The current protection mechanism has proven to be more restrictive than beneficial in such scenarios, leading to frustration and workarounds.

Therefore: We propose reverting the Object.freeze protection in the SignalStore.

If immutability enforcement remains a priority for certain developers, we encourage the community to come up with solutions.

Issues and Disucssions on Object.freeze:

#4649

#4645

#4635

#4676

#4677

#4636

Describe any alternatives/workarounds you're currently using

No response

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

• Yes
• No

[hafnerpw]

This is needed asap

[steven-excelmans]

Thanks for this change, when will this be published? The current version on NPM still contains the freezeInDevMode functionality.

[timdeschryver]

@steven-excelmans this is released a couple hours ago in 19.0.1