React4h estimated

Keys & Lists

Difficulty
Importance

The problem

When a list of items changes — one is added, removed, or reordered — reconciliation needs a way to tell which rendered elements correspond to which data items across renders, or it will guess wrong and produce visible glitches or wasted DOM operations.

Why now

The virtual DOM and reconciliation already established that React diffs trees to minimize DOM changes, but diffing a list by position alone breaks the moment an item is removed from the middle — every item after it shifts position and looks 'changed' even though it didn't. Keys are the missing piece of identity information that fixes this.

Mental model

A key tells reconciliation 'this specific rendered element corresponds to this specific data item, regardless of its position in the list' — without it, React's default guess is array index, which silently breaks the moment items are inserted, removed, or reordered anywhere but the very end.

Requires

Used in

Projects

  • Render a reorderable list using array index as the key, then swap two items and observe an input field's value staying in the wrong place — then fix it with a stable unique key
  • Explain, with a before/after diagram, why index-based keys break specifically on insertion/removal but work fine for a static, never-reordered list

Examples

  • items.map((item, i) => <Item key={i} />) breaks visibly if an item is removed from the middle of the list — use item.id instead
  • A list of chat messages keyed by message ID keeps each message's local state (like an 'edited' indicator) attached to the correct message even as new ones arrive

Resources

Mastery checklist