Why Does React Need Keys for List Items?
Learn why React list items need a stable, unique key, why array index breaks on reorder, and how keys drive reconciliation.
Expected Interview Answer
React needs a stable, unique `key` on list items so its reconciliation algorithm can tell which item in the new render corresponds to which item in the previous render by identity, rather than guessing from array position, which prevents state, focus, and DOM nodes from being misapplied when a list is reordered, filtered, or has items inserted or removed.
Without keys, React falls back to comparing children by their position in the array. This works fine only when a list never changes order and only ever grows or shrinks at the end. The moment an item is removed from the middle, inserted in the middle, or the list is reordered, index-based matching causes React to treat every subsequent item as if its identity shifted by one slot, so it may keep a `<input>`’s DOM node — including whatever the user typed into it, or an uncontrolled component’s internal state — attached to what is now visually a different logical item. A stable key drawn from the data itself, such as a database ID, tells React exactly which previous item a new item corresponds to regardless of position, so React can correctly reuse, reorder, or discard component instances. The key only needs to be unique among its siblings, not globally unique across the whole app, and it should never be regenerated on every render — for example, `Math.random()` or `Date.now()` as a key defeats the purpose entirely because it changes identity every time and forces a full remount.
- Lets React correctly match list items to their previous state after reordering
- Prevents DOM nodes and their internal state (like input focus/typed text) from attaching to the wrong item
- Avoids unnecessary component remounts, preserving performance
- Only needs to be unique among siblings, not globally across the app
AI Mentor Explanation
A React key is like a player’s permanent jersey number printed on the scoreboard, not their current position in the batting order. If the batting order changes, the scoreboard still knows exactly which player’s runs belong to which name because it tracks the number, not the slot. Without that fixed number, swapping two batters’ order could make the scoreboard wrongly credit one player’s score to the other’s name. That fixed-identity-over-position tracking is precisely why React needs a stable key on list items.
Step-by-Step Explanation
Step 1
React renders a list
Each item in an array passed to `.map()` produces a sibling element that needs a key.
Step 2
Key extracted from stable data
A unique identifier from the underlying data (e.g., an id field) is assigned as the key prop.
Step 3
Reconciliation matches by key
On the next render, React matches new elements to previous ones using the key, not array position.
Step 4
Matched items are patched, not remounted
Items with the same key keep their DOM node and internal state; unmatched keys are mounted/unmounted.
What Interviewer Expects
- Clear explanation of why array index breaks for reorderable/filterable lists
- Understanding that keys only need to be unique among siblings
- Awareness that keys must be stable across renders, not regenerated each time
- A concrete example of the bug caused by a missing/wrong key (state or focus attaching to the wrong item)
Common Mistakes
- Using array index as key on a list that can reorder, filter, or have items removed from the middle
- Generating a new key on every render (e.g., Math.random()), which forces constant remounting
- Believing keys must be globally unique across the entire app rather than just among siblings
- Omitting keys entirely and only discovering the bug when list items reorder in production
Best Answer (HR Friendly)
“React uses keys on list items so it can tell which item is which, even if the list gets reordered, filtered, or changed. Without a good key, React can get confused and accidentally mix up which item’s data or state belongs where — like an input box that had text typed into it ending up attached to the wrong row. Using something stable from the actual data, like an ID, instead of the item’s position in the list, avoids that problem.”
Code Example
// Bad: filtering removes items from the middle, but keys stay index-based
// so remaining inputs can inherit the wrong typed-in value after a filter
function TodoList({ todos }) {
return todos.map((todo, index) => (
<input key={index} defaultValue={todo.text} />
))
}
// Good: a stable id ties each input to the correct underlying todo
function TodoList({ todos }) {
return todos.map((todo) => (
<input key={todo.id} defaultValue={todo.text} />
))
}Follow-up Questions
- What specifically goes wrong if you use array index as a key for a reorderable list?
- Does a key need to be unique across the whole app or just among sibling elements?
- How does React use the key during reconciliation to decide whether to patch or remount a component?
- Why is generating a key with Math.random() on every render an anti-pattern?
MCQ Practice
1. What scope must a React key be unique within?
React only needs keys to disambiguate siblings within the same list, not the whole app.
2. What problem can arise from using array index as a key on a reorderable list?
Index-based matching assumes position equals identity, which breaks when order changes.
3. Why is using Math.random() as a key considered an anti-pattern?
A key that changes every render breaks the identity matching keys exist to provide, causing constant remounts.
Flash Cards
Why does React need keys? — To match list items to their previous render by identity, not array position.
What scope must keys be unique in? — Only among sibling elements, not globally.
Why is index-as-key risky? — It breaks when items reorder, are inserted, or are removed from the middle.
Why avoid Math.random() as a key? — It changes every render, forcing unnecessary remounts instead of patches.