Reconciliation, identity and keys

Each evening the porter gets a fresh guest list and must hand each guest a stored bag.

In the analogy	In React
With no claim tags, the porter hands the first bag on the rack to the first guest on the list	No key: pairing by position
A bag keeps its contents; only its outside label is rewritten	A kept component keeps its state; only its props change
A claim tag matching the guest's ticket: the bag is found wherever it sits	A stable key: a moved item keeps its own state
A "claim tag" that just says "rack spot 1"	key={i}: after a re-sort, spot 1's bag goes to a different guest
A ticket with a new tag number matches no bag: the old bag is cleared, the guest gets an empty one	A changed key: unmount, then a fresh mount
The spot now expects a garment bag but holds a suitcase: the suitcase is cleared	A different type at that position rebuilds the subtree

Breaks down when:

• A porter can read the name on a bag; React never inspects props to pair children. Wrong inference: "React will notice whose box this is."
• Claim tags look hotel-wide; keys are unique only among siblings. Wrong inference: "keys must be global IDs."
• An unclaimed bag goes to lost property; destroyed state is gone. Wrong inference: "switching back restores the old draft."

Contrasting case: the safe-deposit ledger, which logs valuables under the guest's name, not a spot: state lifted into the parent and stored by ID (answers[q.id]). Order and keys cannot move it.

In real terms: reconciliation matches each new element to an existing component instance by key, else by index, and reuses it only when the element type matches too; state lives on the matched instance.

E1 gave the same output in headless Chromium with real typing.

E1 · ExamHall EXH-437: "Flagged first" moves answers to the wrong question

Each AnswerBox keeps its draft in state. The candidate types 42 for Q2 and B for Q5, then turns on Flagged first, which moves the flagged Q7 to the top.

list.map((q, i) => <AnswerBox key={i} q={q} />)   // BUG. MR !796: key={q.id}

key={i}: Q7="42" Q2="B" Q5="" | mounts 0, unmounts 0 | Q2's input is the same DOM node: false
key={q.id}: Q7="" Q2="42" Q5="B" | mounts 0, unmounts 0 | Q2's input is the same DOM node: true

Nothing remounts in either run (step 3). With key={i} each draft stays in its slot (step 6); with key={q.id} React moves Q2's own input node (step 5).

E2 · ExamHall: a fresh editor for each attempt

AnswerEditor keeps a draft; the attempt changes from A1 to A2.

<AnswerEditor attemptId={id} />: attempt A2 opens with draft "x = 3" | renders of A2 showing the old draft: 1
<AnswerEditor key={id} attemptId={id} />: attempt A2 opens with draft "" | renders of A2 showing the old draft: 0
useEffect(() => setDraft(""), [attemptId]): attempt A2 opens with draft "" | renders of A2 showing the old draft: 1

Same type, same slot: the draft survives (step 3). The key resets it with no stale render (step 7); the effect clears it one render late.

E3 · Proof domain, chat: position and type decide

The user types to Ana, then opens the group chat.

group ? <Composer to="group" /> : <Composer to="Ana" /> -> "Message group" shows "see you at 6"
group ? <div><Composer to="group" /></div> : <Composer to="Ana" /> -> "Message group" shows ""
{group && <Composer to="group" />}{!group && <Composer to="Ana" />} -> "Message group" shows ""
<Composer key={chatId} to={name} /> -> "Message group" shows ""

Line 1: same type, same slot, so the text would go to the wrong chat (step 3). Line 2 changes the parent's type (step 4). Line 3 uses two slots, since false holds one (step 2). Line 4 resets by key (step 7).