Between rerendering the page or parts of it (in react it's called reconciliation phase) the previous state will be compared to the new state to check if updates are required. Now check the following example why it is useful to change the state immutable:
constoldState=["apple","banana","orange"];// mutableoldState[0]="tomato";constnewState=oldState;oldState===newState;// true - even with different content// or immutableconstupdatedState=[...oldState];updatedState[0]="tomato";constnewState=updatedState;oldState===newState;// false
By changing the state mutable, the actual content of the state has to be compared, which could be a huge performance cost. So all comes down to performance in the end.
EDIT: You can check this great article on LogRocket (see "Performance optimizations in React").
I got it immutable version cut off garbage reference that might cause unexpected change, so I think immutable version bring confidence and to be impossible above mutable situation, really clear. π
And I could notice context about why many people using immutable solution your code example. π¨βπ»
I really appreciate you and I also planing try LogRocket in latest project thanks sharing blog! π€
In the 'mutable' example, oldState === newState is true because they reference the same object: newState points to oldState, which points to an array. Array equality, as I think you allude to, does not look at contents.
In the 'immutable' example, oldState === newState is false because they are not the same object: you've made a copy, so newState points to an array and oldState points to a different array. Again, the equality comparison doesn't care about the contents, only the pointer.
With this in mind, Jannik, does your statement about the performance impact still hold true?
At least on the surface, it seems like the approach you've labeled "immutable" here would be less performant because you're copying the original array instead of reusing it. π€ But I'm honestly not familiar with JS performance traits, curious of your thoughts.
In my opinion you added the missing explanation to my comment π
The first one is mutable because objects (same with arrays and functions) are reference types and therefore changing one variable will also change the other (both pointing to the same object).
You are right, the copying itself is slower than just pointing to the same object. But to compare the oldState and the newState in the "mutable-way" you would have to compare all the values in the object/array and that can be much slower than the copying (just imagine a deeply nested object, eg. cart.products.apple.prices.eur).
Maybe in this example the copying could be slower than the comparison of the values due to the small array.
EDIT:
Just did a quick comparison in performance:
letoldState=["apple","banana","orange"];letnewState;letDOMHasToUpdate=false;// has to update if old and new state are differentconsole.time("mutable");for(leti=0;i<1000000;i++){newState=oldState;DOMHasToUpdate=oldState.map((el,idx)=>el===newState[idx]).includes(false);}console.timeEnd("mutable");console.time("immutable");for(leti=0;i<1000000;i++){newState=[...oldState];DOMHasToUpdate=!newState===oldState;}console.timeEnd("immutable");// OUTPUT:// mutable: 39.876953125ms// immutable: 21.088134765625ms
I know here is no actual change in the state and changing the newState in the mutable way would also lead to an update of the oldState but it is more about the performance for copying vs. comparing values.
But yes, I think my point regarding performance still holds true.
Thank you for your meaningful input with @dabrady
π
I imagined rough mind model about last perfomance comparison mutable like "full-scan", immutable like "check book cover".
Between rerendering the page or parts of it (in react it's called reconciliation phase) the previous state will be compared to the new state to check if updates are required. Now check the following example why it is useful to change the state immutable:
By changing the state mutable, the actual content of the state has to be compared, which could be a huge performance cost. So all comes down to performance in the end.
EDIT: You can check this great article on LogRocket (see "Performance optimizations in React").
Thank you for your qualified comment!
I got it immutable version cut off garbage reference that might cause unexpected change, so I think immutable version bring confidence and to be impossible above mutable situation, really clear. π
And I could notice context about why many people using immutable solution your code example. π¨βπ»
I really appreciate you and I also planing try LogRocket in latest project thanks sharing blog! π€
Hmm, I think your example here might be misleading. If you remove the array mutation from both of your examples, you get the same results:
The strict equality comparator,
===
, does a simple pointer comparison when working with objects and arrays (or "object identity" comparison, if you prefer).In the 'mutable' example,
oldState === newState
is true because they reference the same object:newState
points tooldState
, which points to an array. Array equality, as I think you allude to, does not look at contents.In the 'immutable' example,
oldState === newState
is false because they are not the same object: you've made a copy, sonewState
points to an array andoldState
points to a different array. Again, the equality comparison doesn't care about the contents, only the pointer.With this in mind, Jannik, does your statement about the performance impact still hold true?
At least on the surface, it seems like the approach you've labeled "immutable" here would be less performant because you're copying the original array instead of reusing it. π€ But I'm honestly not familiar with JS performance traits, curious of your thoughts.
In my opinion you added the missing explanation to my comment π
The first one is mutable because objects (same with arrays and functions) are reference types and therefore changing one variable will also change the other (both pointing to the same object).
You are right, the copying itself is slower than just pointing to the same object. But to compare the
oldState
and thenewState
in the "mutable-way" you would have to compare all the values in the object/array and that can be much slower than the copying (just imagine a deeply nested object, eg. cart.products.apple.prices.eur).Maybe in this example the copying could be slower than the comparison of the values due to the small array.
EDIT:
Just did a quick comparison in performance:
I know here is no actual change in the state and changing the
newState
in the mutable way would also lead to an update of theoldState
but it is more about the performance for copying vs. comparing values.But yes, I think my point regarding performance still holds true.
Thank you for your meaningful input with @dabrady π
I imagined rough mind model about last perfomance comparison mutable like "full-scan", immutable like "check book cover".
That is not correct strictly, but I got a chance re-learning around JavaScript's Logical Comparison! π€©πΊ
That's a really nice mental model π