What are keys in React lists and why are they important?
Whether you understand React's reconciliation identity tracking. Keys are unique identifiers that let React match items across renders, preserving DOM state and avoiding unnecessary recreation.
What's really being asked
The interviewer is checking whether you understand that keys are React's mechanism for establishing stable element identity during reconciliation, not merely a lint rule or performance trick. They want to see that you know why identity matters for stateful components, how React matches trees across renders, and what happens when that identity is lost.
The full answer
First, define a key as a unique string or number passed to list elements that serves as a stable identity token for React. Second, explain that during reconciliation React compares the previous tree with the new one; without keys it uses positional index, but with keys it can recognize items that moved, were added, or were removed regardless of position. Third, stress that correct keys preserve component local state and DOM state such as focus and scroll position because React reuses existing component instances instead of unmounting and remounting them. Fourth, clarify that keys must be stable across renders for the same logical item and unique among siblings, though they do not need to be globally unique across the entire application.
The mistakes people make
Calling keys a performance optimization rather than a correctness mechanism. Defaulting to array indices without warning that reordering, inserting, or deleting items can cause state bugs and janky UI. Believing keys are available inside the child component as props, which is false. Thinking React can automatically infer keys from object references or array order.
What usually comes next
The interviewer might ask what happens if you use Math.random as a key on every render. They might ask when array indices are actually safe to use as keys. They could probe how keys affect uncontrolled inputs or component state. They may ask whether sibling lists in different parents can reuse the same key values, or how keys differ from refs.
A concrete example
Consider a todo list where each item has a persistent database ID and contains a text input. If you map over the array and use each todo's database ID as the key, dragging the first item to the second position causes React to recognize that the identities moved and simply reorder the DOM nodes, preserving focus and any draft text inside the inputs. If you use array indices as keys instead, React sees identical keys in the same positions and updates the text content in place, leaving the first input focused but now displaying the second todo's text, which corrupts the user experience.
Interview question
You render a list of stateful text inputs using array indices as keys. After reordering the underlying array, what is the most likely user-visible result?
- a.React uses the items' object references to automatically preserve state and DOM identity across renders
- b.A development warning appears, but the inputs correctly follow their data since indices are valid keys for any list
- c.The inputs remain in their original screen positions but may now show the wrong item's text while keeping their original focusCorrect
- d.React moves the DOM nodes to match the new order, preserving each input's text and focus
Why? this is the answer
With index keys, React reconciles by position rather than item identity, so it reuses existing DOM nodes and updates their content in place, causing focus and draft text to stick to the wrong logical items. Option D describes the behavior only when stable unique keys are used.
Just read this? Test yourself on what you have been reading.
Read the original → react.dev
- #react
- #reconciliation
- #keys
- #lists
- #interview
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on react — each one lists the topics its interview covers.
See open roles