Would need to see the full code for the component/s, bit I’m not sure this is a great example, complex objects + useState aren’t a great fit, I’m not sure where the tutor is going with this (I assume they’ll move on to showing an alternative, like the useReducer hook?). But anyway
So immutability means immutability, so yes, it is required if you want immutability.
However, as you’ve noticed it’s going to make no difference in your current situation.
React is calling functions [which call functions, which call functions, which…] over and over, so to try and do as little work as possible it’s designed to check if the argument/s to those functions are the same value or not – if they’re the same, don’t need to call the function.
Issue with objects is that, if you mutate any properties of the object, that doesn’t change the reference to the object itself: React code will happily say “yep, nothing’s changed, no need to rerun this function”.
So by making sure everything is immutable, that stops being a problem – if you update some properties of an object, you make a new object. React code sees it’s a different value, updates.
In this situation, you copy the object (an array in this case), mutate the properties, set the state to the copy. React registers that there’s been a setState call. Pass the new state in as an argument to the component function it’s attached to. State has definitely changed, it’s a new object, rerender.
(Conversely, if you mutated directly: you mutate the properties, set the state. React registers that there’s been a setState call. Pass the state in as an argument to the component function it’s attached to. State has not changed, it’s not new object, don’t rerender).
If that component rerenders, if its state actually changes in a way visible to React (via the new object), then by default so does everything under that component.
If you have some specific child component that depends on that specific (non-copied) property [possibly only if that component is memoised, but it depends on structure], mutating values on that object will then in turn mean that you get the problem described above – the array is a collection of objects, the reference to each object never changes, the component that depends on that specific object will not get new arguments.
Hope that kinda makes sense, as I say would need to see more code.
Overall, immutability tends to help make React code easier to grok (easier to see what will change and when) and as a rule of thumb generally more efficient. But JS doesn’t have immutable data structures, so doing it manually is fiddly and doesn’t always make any difference – this is why immutability libraries are relatively popular (not using big complex objects in state is normally easier tho)