Why must React state updates be immutable? | Interview Question

Q: Why must React state updates be immutable?

**Target Audience:** Engineers preparing for senior React interviews — assumes state basics. **Difficulty:** Hard > **How to read this doc:** Concepts are explained in plain language first, then tagged with 📌 Interview term: . The render counts and the delayed corruption in section 3 were produced by actually mutating state on React 19.2.8. ## 1. Why This Even Matters — A Story First A librarian checks whether a shelf has changed by looking at the label on its end, not by reading every spine. Reading every spine on every shelf, constantly, would take all day. The label is a cheap proxy — and it works perfectly, provided everyone follows the rule: **change the shelf, print a new label**. Someone who quietly slips a book onto a shelf without reprinting the label has not just failed to notify anyone. They have made the label **lie**. And nobody will notice until the next time that shelf is legitimately relabelled — at which point a book appears from nowhere. That is exac

The problem

Question presented to candidate: "Why can you not just push to an array in state and call the setter with the same array?"

What a strong answer should cover:

React decides whether state changed by comparing the reference with Object.is — a shallow, identity check, never a deep one.
Mutating in place leaves the reference identical, so React sees no change and bails out of re-rendering entirely.
The dangerous part is not the missed render, it is that the mutation still happened. The data is now wrong and the screen is stale, and the corruption surfaces later during an unrelated update.
Why reference comparison: deep-comparing every state value on every update would be prohibitively expensive, and impossible for functions.
Immutability is also what makes React.memo, useMemo dependency arrays, and context value comparison work at all — they are all reference checks.
It underpins concurrent rendering: React can hold a previous state value and render both, which is impossible if the object was mutated in place.
The patterns: spread for objects and arrays, map/filter/toSorted rather than splice/sort/reverse, and a library like Immer when nesting gets deep.
StrictMode freezes state in development for some cases; the discipline is required regardless.

Clarifying questions expected:

"Is the state deeply nested? That changes whether I would hand-spread or reach for Immer."

Code / implementation expected: Yes — the mutation that silently does nothing, beside the correct copy.

react
state
immutability

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Engineers preparing for senior React interviews — assumes state basics. Difficulty: Hard

How to read this doc: Concepts are explained in plain language first, then tagged with 📌 Interview term:. The render counts and the delayed corruption in section 3 were produced by actually mutating state on React 19.2.8.

1. Why This Even Matters — A Story First

A librarian checks whether a shelf has changed by looking at the label on its end, not by reading every spine. Reading every spine on every shelf, constantly, would take all day. The label is a cheap proxy — and it works perfectly, provided everyone follows the rule: change the shelf, print a new label.

Someone who quietly slips a book onto a shelf without reprinting the label has not just failed to notify anyone. They have made the label lie. And nobody will notice until the next time that shelf

The solution is hidden so you can try first

6 min read · 8 sections

Try it in the playground

Open any example in the playground to run and change it.

ReactThe mutation that does nothing, then reveals itself later

Open in playground

import { useState, useRef } from "react";

export default function App() {
  const [items, setItems] = useState(["apple", "banana"]);
  const [log, setLog] = useState([]);
  const renders = useRef(0);
  renders.current++;

  const push = (line) => setLog((l) => [...l.slice(-4), line]);

  // ❌ Mutates in place, then hands React the SAME reference. Object.is says
  //    nothing changed, so React bails out — but the array really did change.
  const mutate = () => {
    items.push("mutated-" + Date.now().toString().slice(-4));
    setItems(items);
    push("mutated + setItems(same ref) — expect no visible change");
  };

  // ✅ Builds a new array. New reference, so React re-renders.
  const copy = () => {
    setItems((prev) => [...prev, "copied"]);
    push("setItems(new array) — re-renders");
  };

  // ❌ sort() mutates AND returns the array, which is why it fools people.
  const sortBadly = () => {
    setItems(items.sort());
    push("items.sort() — mutates in place, same ref");
  };

  // ✅ toSorted() returns a new array, leaving the original alone.
  const sortWell = () => {
    setItems((prev) => prev.toSorted());
    push("toSorted() — new array");
  };

  return (
    <div style={{ padding: 24, fontFamily: "system-ui", lineHeight: 1.6, maxWidth: 520 }}>
      <p style={{ fontSize: 14 }}>
        renders: <strong>{renders.current}</strong> · items in state:{" "}
        <strong>{items.length}</strong>
      </p>

      <ul style={{ background: "#f6f6f6", padding: "8px 8px 8px 28px", borderRadius: 6 }}>
        {items.map((it, i) => <li key={i}>{it}</li>)}
      </ul>

      <p>
        <button onClick={mutate} style={{ marginRight: 6 }}>❌ mutate</button>
        <button onClick={copy} style={{ marginRight: 6 }}>✅ copy</button>
        <button onClick={sortBadly} style={{ marginRight: 6 }}>❌ sort()</button>
        <button onClick={sortWell}>✅ toSorted()</button>
      </p>

      <pre style={{ background: "#f6f6f6", padding: 10, borderRadius: 6, fontSize: 12 }}>
        {log.length ? log.join("\n") : "(press a button)"}
      </pre>

      <p style={{ color: "#666", fontSize: 13 }}>
        Press ❌ mutate two or three times — nothing appears to happen. Now press
        ✅ copy once: every hidden mutation shows up at the same moment. That
        delay between cause and symptom is what makes mutation so hard to debug.
      </p>
    </div>
  );
}

Discussion

Other approaches, follow-ups and how it went in real interviews.

Sign in to join the discussion.

No comments yet. Share how you would answer it.

The solution is hidden so you can try first

Keep your momentum going.