SignalStore: Update V19 - breaking changes

[leomayer]

The upgrade to V19 causes some problems which I'm finally not clear how to solve it.

According to the documentation I should use an immutable approach. While this works for primitives I have no clue how this works for complex default Angular Material Controls. I have in my initial state

uiFormGroup: FormRecord;

which is used like

this.propStorage.uiFormGroup().addControl(name, this.getMyControl());

The FormRecord isn't changed by itself. But when I try to add a control I get an exception like

ERROR TypeError: Cannot add property .... , object is not extensible

How is it supposed to work with V19 since neither the spread nor the structuredClone helps.

It worked already with V18?

[rainerhahnekamp]

In v19 the state object is frozen for your own safety. You don't want to have mutable changes to a Signal.

In your case, you have FormRecord in the state where Object.freeze throws that error.

At the moment, the solution is not to put FormRecord into it. An alternative solution is to offer the possibility to opt out of the state freezing.

[leomayer]

I'm confused how the definition should look like. Cause right now I have the initial state and where to define your suggested approach? I didn't find a 'withProps' in the documentation. You mean I should define it in a 'withComputed' and there as props??? And what to do with the initial state?

[markostanimirovic]

withProps documentation is available at the following link: https://ngrx.io/guide/signals/signal-store/custom-store-properties

const MyStore = signalStore(
-  withState({ form: new FormGroup({ /* ... */ }) }),
+  withProps({ form: new FormGroup({ /* ... */ }) }),
);

[leomayer]

But this won't work - see

https://stackblitz.com/edit/github-f4exnwqd?file=src%2Fquiz.store.ts

Same as #4655? If not, how to correct the example?

[rainerhahnekamp]

Now it is working, you need to import the types 😉:

https://stackblitz.com/edit/github-f4exnwqd-mp8fcvm4?file=src%2Fquiz.store.ts

[leomayer]

Thx for the support and ongoing discussion. It seems that I've just follow @markostanimirovic sample and didn't take care about the additional considerations for dependency injections.
Seems like that thanks to @rainerhahnekamp I could make a progress on my migration path. Just few remarks nevertheless:

1. For me it seems strange to have one definition with function and one without. Honestly I don't understand the difference, because discussion arguments for the one or the other might apply mutually.

withState(initialState),
withProps(() => initialProps),

2. With the props I have a "confirming" question: Is it correct to say

• the props are treated as independent property of the Store
• they can be accessed from anywhere
• they are immutable but can be updated as needed
• I don't get any kind of updates on changes like for Signals

[leomayer]

As an additional comment to the current situation:

I have my component with 3 input fields, which are used for search. All 3 of them are combined into an object and is used in some other places of my already existing code. Right now I cannot forward the search-objects reference from the SignalStore to my component. Well I can forward the reference and it compiles. But any kind of update in my component would change the referred object in the Signal-Store and therefore throw an Error.

I did expect from the Store to keep the State of the components field and therefore I've coded it like this way. Honestly I'm really confused right now what's expected about the functionality of the Store. Seems like there is a gap between what is provided in V18 and what's the new design.

[rainerhahnekamp]

I personally think that you should separate the state from the FormControls. The state should be located in the SignalStore but not in the form of FormControls but as a simple state. And this is not something that has changed between v18 and v19. This is something which is valid since the early days of state management.

You probably have just one component where the state is used within a Form. If yes, that component should inject the SignalStore and load the state into the FormGroup. effect(() => this.formGroup.setValue(this.store.data())).

One the user hits submit, you take the data and load it back into the SiganlStore.

onSubmit() {
  this.store.setData(this.fromGroup.value);
}

By that, you have a synchronization between form and store and your other components can access the state - as it is - from the store instance.

[leomayer]

While I would agree if you have some kind of fixed Form the problem starts to get tricky when the form is dynamic. Then I have to handle the fields => the fields must be handled and memorized in some way. Therefore I was thinking that the signalStore is the only source of truth. But seems like I need to rethink this paradigma.

[leomayer]

Just as general question to these changes:

If I understand it correct than I have

1. withState(initialState) AND
2. withProps(initalProperties)

The first are immutable and cannot be changed; not even the content. If I want to adapt the content I need to run patchState.
The second allows changes on the object - since its a property. (Don't know if the object itself can be reassigned, but ...).

My q: I can define initalProperties as prop: WriteableSignal<InitProps> - which means than I have everything as before? Or do I miss something?

So, basically the BreakingChange in V19 is to distinguish between Signals which cannot be changed from outside (=similar to the _ prefix) and the some which are changeable.

[rainerhahnekamp]

I can define initalProperties as prop: WriteableSignal<InitProps>

Yes, but you are loosing the additional protection from the SignalStore. Whenever you have an mutable change, the signal will not notify its consumers. These are issues which are extremely hard to debug.

basically the BreakingChange in V19 is to distinguish between Signals which cannot be changed from outside

No, the protectedState is something we have since V18. V19 runs recursively Object.freeze on the state's value.

[leomayer]

• V18 has had some Object.freeze on the states
• V19 has either some deep freeze (MDN) or no protection at all (props).

And agreed that "no protection" makes things hard to debug. Although this is "works as designed" I don't see the benefit in it.

Anyway - thx for clarification. From my point of view we can close this discussion.

[rainerhahnekamp]

You need to mark it as answered, so that it is closed.

For more information: https://github.com/rainerhahnekamp/ngrx/blob/docs/signals/immutability-protection/projects/ngrx.io/content/guide/signals/faq.md

V18 didn't have Object.freeze. patchState just didn't (and still does) allow you to update the state from the outside. V19 introduced Object.freeze. props is only the solution if it shouldn't be reactive.

[leomayer]

Most of the requested points are answered. Thx very much.