Angular Signals enforce Immutability in v17

I show you in this video that the latest stable version of the Angular Signals will have a breaking change with potentially huge consequences.

It is not the missing mutate function, but the internal equality check.

They cause that Signals will not trigger if we change them mutably.

[BrendanAlexander]

Thanks good video. I discovered this, after upgrading to 17.1, and it called out "mutate" as no longer supported. Am kind of bummed about this, but I can live with it.

[farrukhmomin]

Highly appreciate you work and simple explanation. I agree with enforcing immutability but why not have a flag where user is to say whether they what mutability when they are initializing signals.

[grerff]

So I won't be able to add an element to the array by just pushing it, will I have to do it by destructuring? I don't like it

[tevend]

so would the work-around in your example just be to return { ...value, clicked: true } from the update ?

[magnifico]

It is a great decision to make angular immutable by default as they are moving to FP

[KostasOreopoulos]

Well, I can think of an easy way to bypass that (without testing it so it might not work)

If I have a large array, and I am not willing to copy it again and again, for performance reasons, and I have a computed value that involves, I will create a boolean value (or any other value) that I will act as a flag and will trigger the computed recalculation. I will just change that value and it will trigger the computed signal

But only for those structures that will impact performance.

[vadimr]

Thank You! Is this for good or not? What do you think about this changes?

[AramPetrosyan-fp]

Of course, it's not for me to judge! Initially, in version 16, I was thrilled that there was finally an opportunity to disable change detection and mutate an object. This feature is incredibly convenient to use, highly flexible, and eliminates the need for excessive manual intervention. However, for the sake of junior developers, this function was removed. In my project, a significant amount of code is written using the 'mutate' function.

To be honest, I don't think that this somehow interferes with the work of NGRX or other state management systems. We can work with it perfectly outside of the component and within the component, simply mutating the data that we intend to manipulate.

I don’t believe it bothered anyone much. Really, if you don’t want to mutate an object, you don't have to. Why remove the functionality? If you don't want to use it, then don't use it. If you want to use it, go ahead and use it.
So, removing functionality that was integrated into the previous version seems unnecessary and creates more problems (at least for me). Well, I think this, but it’s not for me to judge, guys. It’s not for me to judge!

Thanks for the video!