Use practical immutability with objects and arrays so UI state and business logic stay easier to reason about, test and debug.
When the same object reference is shared across flows, one hidden write can change behavior far away.
Mutation is not always wrong, but it becomes risky when multiple parts of the app assume they are reading stable state.
Once state changes happen implicitly, tracing where a bug came from becomes much harder.
Create a new object or array instead of mutating the old one in place.
For objects, the spread operator is often enough for shallow updates. For arrays, methods such as `map`, `filter` and spread usually keep intent visible.
This style works especially well when UI rendering depends on detecting clean state transitions.
The highest value usually appears around shared state, reducers, UI rendering and domain transformations.
If a function receives state and returns next state, immutability makes that contract much clearer.
Local temporary variables inside a narrow function may not need the same strictness if they never escape that scope.