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".
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 π