In React, a component of the same type is rendered with key="a" on one render and key="b" on the next, with identical props. What does the reconciler do to its fiber, its hook state, its DOM node and its effects?

## Why the key alone decides it When a parent reconciles its children, the first thing it asks about a candidate pairing is whether the keys are equal. Only if they are does it go on to compare the element type. So `key="a"` becoming `key="b"` short-circuits reuse immediately: as far as the reconciler is concerned, the element named `a` is gone from this child list and an element named `b` has appeared. Identical component type and identical props change nothing — they are never consulted. The result is two operations in the same reconciliation: the fiber for `a` goes on the parent's deletion list, and a fresh fiber is created for `b`. ## What happens in the commit The render phase only decides; the commit phase performs. For the deleted subtree: - `useLayoutEffect` cleanup functions run, and for class components `componentWillUnmount` runs; - refs pointing into that subtree are detached — a `useRef` object's `current` is set back to `null`, and a callback ref is called with `null` (in React 19 a callback ref may instead return a cleanup function, which is invoked here); - its DOM nodes are removed from the document; - `useEffect` cleanup functions for the removed tree run in the same commit's passive phase, before the new tree's effects are set up. For the newly mounted subtree: - every `useState` initialiser and `useReducer` initial value is evaluated again from scratch; - `useRef` produces a brand-new box; - new host DOM nodes are created and inserted; - every effect in the subtree runs as a first mount, dependencies included. ## What is lost, concretely Everything that lived on the old fiber or its DOM node is gone: `useState` and reducer state at every level of the subtree, `useRef` values, uncontrolled input text, focus, text selection, scroll position within the subtree, in-flight CSS transitions, and any imperative state a third-party library attached to the removed nodes. Children are not spared — a key change at the top remounts the entire subtree beneath it, because those children are reconciled against nothing. ## Contrast with the same key If the key had stayed `"a"` and only the props changed, the picture is the reverse: the same fiber is kept, the new props are applied to it, hooks keep their stored state, the DOM node is patched with only the attributes that actually differ, and effects re-run only if their dependency arrays changed. That is the whole difference between updating and remounting, and it is decided by one string comparison. ```jsx // same fiber, state preserved, DOM patched <Editor key="draft" value={next} /> // different fiber: old one unmounted, new one mounted fresh <Editor key={documentId} value={next} /> ``` ## Why this is not free Because the mechanism is a genuine unmount and mount, its cost scales with the size of the subtree: new fibers, new DOM nodes, all effects re-running, any data those effects fetch re-fetched. On a large subtree in a hot path, a key that changes more often than the identity it is supposed to represent turns every update into a full rebuild — which is exactly the failure mode of keys derived from something unstable. ## The ordering detail interviewers like Within a single commit, React finishes tearing down the removed tree before running the new tree's effects. So a subscription established in an effect is unsubscribed before the replacement subscribes, and two subscriptions never overlap. That ordering is the reason a key change is a clean identity swap rather than an overlapping pair of lifecycles. ## Answering well Say plainly: key checked first, so no reuse; old fiber deleted with cleanups, refs and DOM; new fiber mounted with fresh state and effects; whole subtree, not just the component; and it costs proportional to that subtree.