Explain key or trackBy in list rendering and index key risks

WHAT THIS TESTS:

This question probes whether you understand reconciliation at a semantic level, not just as a black-box optimization. The interviewer wants to see that you know key or trackBy is an identity contract between your data and the DOM, not decorative syntax. Senior candidates should connect this to component state preservation, transition correctness, and predictable event handler binding.

A GOOD ANSWER COVERS:

First, define key or trackBy as a unique identifier that tells the framework which data item corresponds to which existing DOM node across renders. Second, explain the concrete benefits: the framework can reuse elements instead of destroying and recreating them, it can preserve internal component state like form inputs or scroll position, and it can execute move transitions correctly when order changes. Third, describe the index-as-key failure mode: when an array is reordered, filtered, or prepended to, the index of every item shifts, so the framework thinks the identity of every node changed even though the underlying data objects are the same. Fourth, mention that stable unique IDs from your data model, such as database primary keys or UUIDs, are the correct source for key values.

COMMON WRONG ANSWERS:

A red flag is saying key is only for performance or that it is optional in production. Another is claiming index is fine for all cases because you have not noticed bugs yet. Some candidates describe the problem only in terms of extra DOM operations without mentioning state corruption or visual glitches. Avoid suggesting Math.random as a key, since that forces recreation on every render and destroys the very identity tracking you are trying to achieve.

LIKELY FOLLOW-UPS:

The interviewer may ask how key interacts with component lifecycle hooks, specifically why a stable key prevents destroy or recreate cycles while a changing key forces remount. They might ask what happens when key is duplicated across siblings, which typically triggers a runtime warning and unpredictable patching behavior. You could also be asked to compare Vue's key to React's key or Angular's trackBy, where the underlying identity concept is identical even if the API surface differs.

ONE CONCRETE EXAMPLE:

Imagine a todo list where each row contains a checkbox and a text input. The todos are sorted by priority. If you use the array index as key, sorting the list will reuse the existing DOM nodes in their original positions. The first DOM node, which previously held the checked state for Todo A, now receives the props for Todo B, but the internal checkbox state remains checked from Todo A. The UI now shows Todo B as checked even though the data says it is not. Additionally, if you have CSS transition animations on list items, the framework cannot detect that Todo A moved to position three because all keys changed, so no move animation fires and the list snaps instantly.