Lesson 6 of 80

Reconciliation & Keys

Q: Why shouldn't you use the array index as a key in a list that can reorder? Walk me through the actual mechanism, not just the rule.

A strong answer covers: React compares the new element tree to the previous one and matches list items by key, not by data; With index as key, a reorder or insertion shifts which item sits at each index, but the key values stay put; React believes the element at a given key is 'the same one, just updated' and reuses its DOM node and internal state — attaching the wrong item's state to the wrong item.

How React decides which real DOM changes are actually needed — and why a list without stable keys can attach state to the wrong item.

14 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 4

A list uses key={index}. A new item is inserted at the front, shifting every other item's index by one. What's the likely consequence?

Local state can end up attached to the wrong item after the shiftReact automatically detects the insertion and shifts state correctly regardless of the keyThe whole list re-mounts from scratch, so there's no bug, just wasted work

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Reconciliation & Keys

What interviewers actually ask about this, and what a strong answer has to cover.

Why shouldn't you use the array index as a key in a list that can reorder? Walk me through the actual mechanism, not just the rule.

A strong answer covers

React compares the new element tree to the previous one and matches list items by key, not by data
With index as key, a reorder or insertion shifts which item sits at each index, but the key values stay put
React believes the element at a given key is 'the same one, just updated' and reuses its DOM node and internal state — attaching the wrong item's state to the wrong item

Likely follow-ups

When is index-as-key actually fine to use? What has to be true about the list?
If the key matches at a position but the element type changed there, what does React do — update in place, or something else?
Would this same bug happen if every item's key were globally unique across the whole app, versus just unique among its siblings?
If you were manually updating a list of DOM nodes with no React at all, how would you decide which nodes to update in place versus tear down and rebuild — and how does that compare to what a key does?

Practice these with the AI interviewer →

The plain-language idea

Every render produces a brand-new description of the UI. React doesn't throw away the real DOM and rebuild it from scratch each time — that would be slow and would lose things like input focus and scroll position. Instead, reconciliation compares the new description to the previous one and computes the smallest set of real DOM changes needed to catch up.

For a list of children, React needs a way to tell "this is the same item, just moved" apart from "this is a different item entirely." That's what key is for.

See it in a real thing: state landing on the wrong item

{items.map((item, index) => (
  <Row key={index} item={item} /> // ❌ index as key
))}

If items gets reordered — say a new item is inserted at the front — every item's index shifts, even though the items themselves didn't change. React matches by key, so it now thinks "index 0" is still the same Row it was before, just with different props. It reuses that DOM node and whatever internal state it was holding — attaching the wrong item's state to the new item now sitting at that position.

Reconciliation: why keys matterStep 1 of 4

Three items render as a list. Item B has its own local state — an input holding “hello”.

What people usually miss

Watch out

Keys only need to be unique among siblings, not globally across the whole app. The same key value can appear in two different lists without conflict.
Using array index as a key is fine when the list never reorders, is never filtered, and items are never inserted/removed from the middle. It's specifically reordering/insertion/deletion that breaks it — a static list is safe.
A key mismatch doesn't just misplace state — it can also cause React to unnecessarily tear down and rebuild a DOM node, when the element type actually changed at a given key (e.g. a <Row> swapped for a <div>), losing any transition/animation state on it too.
Reconciliation compares by type AND key together, not key alone. Same key, different element type at that position → React unmounts the old one and mounts a fresh one instead of updating in place.

Why this matters in interviews

"Why shouldn't you use the array index as a key?" is one of the most common React interview questions precisely because the failure mode is subtle — nothing crashes, no warning is guaranteed to be obvious, state just silently ends up attached to the wrong row. Explaining the actual mechanism (React matches by key, not by data) is what separates "I know the rule" from "I know why the rule exists."