Reconciliation and keys: where your state actually lives

The diff is a heuristic, not a tree search

A true minimal diff between two trees costs O(n³) — for a thousand elements, on the order of a billion comparisons, dead on arrival for a UI that re-renders on keystroke. React refuses to play that game and instead bets on two heuristics that are almost always true in real UIs. First: two elements of different types produce different trees — if a position held a div and now holds a section, or held a UserProfile and now holds a LoginForm, React does not look inside. It unmounts the entire old subtree (destroying all state in it, running effect cleanups, removing DOM) and mounts the new one from scratch. Second: the developer can mark stable identity across renders with a key. With these two assumptions, reconciliation runs in O(n).

The comparison itself works position by position. Same type at the same position: React keeps the existing fiber, updates its props, and recurses into the children — the component instance survives, its hooks survive. Different type: full teardown of that subtree. This is also why the comparison is between element descriptions, never between component “instances” — elements are recreated as fresh objects on every render and carry no state at all. They are throwaway descriptions; the fiber is the persistent thing they get matched against.

State lives on the fiber, and the key is the matching rule

When you wonder why your input keeps its typed text across re-renders, the answer is: everything useState gives you is stored on the fiber, not in your JSX and not in the closure of your function — the function ran and returned; its locals are gone. So the question “where is my input’s text?” has a precise answer: on the fiber that React matched to your element during the last reconciliation. For a single child, matching is by position and type. For an array of siblings, position is meaningless — lists get reordered, filtered, prepended — so React matches siblings by key: the old fiber with key “a” pairs with the new element with key “a”, wherever it moved. A matched fiber keeps its state and its DOM node, and the move costs one DOM reposition instead of a teardown.

Now the failure mechanism from the Hook, precisely. With key={index}, the key is the position — you have re-stated the default and disabled the entire matching machinery. Reorder the data and React sees: position 0 still has key 0, same type → same fiber → same state. The fiber holding the manager-draft now receives the candidate-conversation’s props. Everything that lives on the fiber or its DOM node sticks to the position instead of following the data: uncontrolled input text, checkbox state, focus, scroll position, useState inside the row, even memoized values. Deleting the first item is the same bug in another costume: every fiber shifts to a new data item, and the last fiber gets unmounted — so “I deleted row one, but row two’s notes vanished and row one kept the deleted ticket’s notes.”

const [convos, setConvos] = useState(initialConvos);
// convos re-sorts when any thread gets a new message

// Bug: key restates the position. After a re-sort, the fiber (and the
// uncontrolled input state on it) at position 0 is matched to whatever
// conversation now sits at position 0.
{convos.map((c, index) => (
  <ConversationRow key={index} convo={c} />
))}

// Fix: key = stable identity from the data. The fiber follows the
// conversation wherever it moves; React repositions the DOM node.
{convos.map((c) => (
  <ConversationRow key={c.id} convo={c} />
))}

Two corollaries seniors get asked in review. key={Math.random()} is the opposite bug and strictly worse: no key ever matches, so every render unmounts and remounts every row — state wiped each render, effects re-run, full DOM rebuild; a 200-row table goes from a handful of patched nodes to 200 teardown-and-create cycles per keystroke. And keys only need to be unique among siblings, not globally — item.id is fine even if another list elsewhere uses the same ids.

Element identity vs component identity: the resets you did not order

The flip side of “same type keeps state” is that same component type at the same position keeps state even across completely different JSX branches. Render <Counter person="Taylor" /> in the true branch of a ternary and <Counter person="Sarah" /> in the false branch: toggling does not reset the count. React sees position 1, type Counter, both times — same fiber, props updated, state preserved. If those are logically different counters, that is a bug you fix by giving the branches different keys — key="taylor" and key="sarah" — turning the key into a deliberate reset lever. The same lever resets a form when the entity changes: <ProfileForm key={userId} /> remounts the whole form on user switch instead of leaking one user’s edits into another’s profile.

And the inverse failure: defining a component inside another component. The inner function is recreated on every parent render, so its identity differs every time; React compares by reference for function types, sees a “different type” at the same position, and unmounts the subtree — every parent render wipes the child’s state, refocuses nothing, replays mount effects. It looks like “my input loses focus on every keystroke” and is among the most-filed non-bugs in React’s tracker. Hoist the definition to module scope; if it needs the parent’s data, pass props.