.map(), .filter(), .sort(), or .reverse() all behave the same way regarding mutation — .sort() and .reverse() mutate in place, the rest don't..sort() on numbers without a comparator, silently getting string-based lexicographic order instead of numeric order..forEach() and expecting a return value, or trying to break out of it early — neither works; use .map()/.reduce() or a for...of loop instead..reduce() without an initial value on an array that might be empty, causing a TypeError.|| for a default value when 0, "", or false are legitimate values — ?? is almost always the more correct choice for that case....) or Object.assign() performs a deep copy — both are shallow, and mutating a nested object afterward leaks back into the "copy's" source.=== expecting a contents comparison — it always compares references for non-primitives.Map-shaped problem (arbitrary key types, frequent insertion/deletion, needing a reliable .size) and fighting string-key coercion as a result.These same methods are exactly what shows up, in slightly rearranged form, inside useState/useReducer updates in React Fundamentals — React's insistence on new array/object references for every state update is precisely why the mutating-vs-non-mutating distinction at the top of this reference matters so much in practice. See JavaScript Core Concepts for the scope, closure, and async mechanisms these methods run inside of.
Try several of these as real, runnable exercises in the code lab.