"Why does React need a key prop?" is really a question about identity. React compares a new description of the UI with the previous one, and a key tells it which child is still the same item after a list changes.
Get identity right and the famous list-reorder bug, where text typed into one row turns up under a different name, stops looking mysterious.
What the virtual DOM actually is
A rendered React element tree is a lightweight JavaScript description of what the interface should look like. It contains element types, props and children. When props or state change, rendering produces a new description.
The virtual DOM is not a second browser DOM and is not valuable because JavaScript objects are automatically "faster than the DOM." It is a comparison target. React can inspect the old and new element trees, decide what changed, then commit the required operations to the real DOM.
Keep three layers separate:
Component state and props are inputs to rendering.
Rendering produces an element tree describing the desired UI.
Reconciliation compares descriptions, and the commit updates the real DOM.
That separation also explains why rendering should stay pure. It describes the next UI rather than directly editing the page.
Reconciliation and the diffing heuristic
React needs to match old elements with new elements before it can decide what to keep, update or remove. A general tree-diff algorithm can require O(n^3) work. React uses an O(n) heuristic based on two practical assumptions:
Elements with different types produce different subtrees.
Developers provide stable keys to identify children across renders.
The result is not a mathematically minimal edit script for every possible tree. It is a predictable and efficient rule set that works when component types and keys express identity correctly.
This is the core interview answer: reconciliation is React's process for matching the previous and next trees so it can preserve the right nodes and update the rest.
The three diff rules
Different types mean different subtrees. If a root element changes from <div> to <span>, React removes the old subtree and creates a new one. Component instances below that boundary are unmounted, so their local state is lost.
The same type can be updated. If <div className="a"> becomes <div className="b">, React keeps the existing DOM node and changes the relevant attribute. For a component of the same type, React can preserve its state while rendering it with new props.
Children are matched by key. In a list, keys identify which old child corresponds to which new child. Without explicit keys, React falls back to positional matching and warns for generated lists.
A key is not decoration for the warning. It changes the identity evidence reconciliation uses.
Why keys matter in a reordered list
Suppose a list renders uncontrolled inputs:
const names = ["Asha", "Bimal", "Chirag"];
return names.map((name, i) => (
<label key={i}>
{name}
<input defaultValue={name} />
</label>
));The user edits the three input values. Then the data becomes:
["Chirag", "Asha", "Bimal"]With key={i}, the old keys are 0, 1, 2 and the new keys are still 0, 1, 2 in those positions. React matches old position 0 with new position 0, old 1 with new 1, and old 2 with new 2. The labels change, but the existing uncontrolled input DOM nodes stay in place. Their current typed values belong to those DOM nodes, so the text appears under the wrong names.
React still rewrites each label and still hands the input its new defaultValue. That second write only changes the field's default, and a browser leaves an edited field's current text alone when its default changes, so the typed values stay exactly where they were.
Now use stable identity:
return names.map(name => (
<label key={name}>
{name}
<input defaultValue={name} />
</label>
));React can match the old "Chirag" child at index 2 with the new "Chirag" child at index 0. It moves that existing node, carrying its DOM state with it. The same applies to Asha and Bimal. The values stay attached to the people they belong to.
Uncontrolled inputs make the effect visible. The DOM node itself owns the typed value, so preserving or discarding a node identity shows up as text on screen instead of hiding inside component state.
The index-as-key bug
An array index is safe as a key only when the list is truly static: items never reorder, no item is inserted or removed in a way that shifts positions, and filtering never changes which item occupies an index. Those conditions are stricter than "it works on the first render."
Use a stable unique identifier from the data, normally a database ID. A person's display name works only in this tiny example because the names are unique and stable. Real records should use their actual IDs.
Do not use Math.random(). A new random key on every render tells React that every child is new. It remounts the list, loses local state and performs unnecessary work.
Key traps interviewers probe
Keys need to be unique among siblings, not throughout the application. Two separate lists can both contain a child with key 42 without conflict.
Keys must also be stable across renders. Changing a component's key intentionally forces React to treat it as a new identity, which remounts it and resets its state. That can be useful for resetting a form, but accidental key changes are a bug.
The key value is used by React and is not passed to the component as an ordinary prop. If a component needs the record ID, pass it separately, for example <Row key={item.id} id={item.id} />.
Interviewers ask you to define reconciliation, predict an index-key reorder, say when an index is acceptable and explain why random keys are worse. React interview questions for freshers places these probes beside the other common rendering questions.
KnowledgeGate's MERN practice questions cover React rendering and key behaviour alongside Redux, Node and MongoDB. Working through them is the natural next step once you want to connect preserved node identity with preserved component state.
The short version and next step
The virtual DOM is a diff target. Reconciliation keeps same-type nodes where identity matches, rebuilds different-type subtrees and uses keys to match list children. Stable keys let state move with the item; index keys tie it to a position that may stop representing that item.
Use the Complete React and Redux course for the rendering model and the MERN Stack and DSA bundle for full-application practice. The Coding and DSA courses catalog covers the algorithm rounds that sit either side of a frontend interview.
