React List Identity

Stable keys let React associate rendered elements with the same logical items when a list changes. This preserves the intended component identity, including local state and DOM state, across insertions, deletions, and reordering.

When React renders a list, each sibling element can have a `key` that identifies which item it represents. During a later render, React uses keys together with the element type to determine which existing component instances can correspond to the new elements.

A good key comes from stable identity in the data, such as a database ID. It should remain associated with the same logical item even when the item's position changes. Keys only need to be unique among their sibling elements; they do not need to be globally unique.

Using an array index as a key can cause problems when items are inserted, removed, or reordered. React may associate an existing component instance with a different data item, which can make local state, focus, input values, or other DOM state appear to move to the wrong row.

Keys are primarily an identity mechanism for React's reconciliation process; they are not passed to the component as a normal prop. If a component needs the identifier, pass it explicitly, such as `itemId={item.id}`.

Changing a component's key intentionally can make React treat it as a different instance, causing the previous instance to be discarded and a new one to mount. This can be useful when a component should reset its local state.

Key points

• Use a stable key derived from the item's identity, such as `id`.
• Keys must be unique among sibling elements, not across the entire application.
• Avoid array indexes as keys when a list can be reordered, inserted into, or deleted from.
• A key helps React preserve the correct component instance and its local state.
• `key` is not available through `props`; pass an identifier separately when the component needs it.

Interview questions

Is a key passed to the child component as a prop?

No. React treats `key` as a special value used during reconciliation rather than as an ordinary component prop. Therefore, reading `props.key` does not provide the key value to the component. If the component needs the same identifier, pass it explicitly as another prop, such as `itemId={item.id}`.

Why does React need keys when rendering lists?

Keys give React a stable way to identify children between renders. When a list changes, React can use those identities to determine which elements correspond to existing component instances. This helps preserve the appropriate local state and DOM state. A key should represent the item's identity rather than merely its current position.

Why is using the array index as a key sometimes a bug?

An index identifies an item's position rather than the item itself. If an item is inserted, removed, or moved, the indexes of other items can change. React may then reuse a component instance for a different logical item, potentially moving local state or input state to the wrong row. Index keys are less problematic when the list is genuinely static and never changes order or membership.

Where should a React list key come from?

Ideally, the key comes from a stable identifier already associated with the data item, such as a database ID. The same logical item should receive the same key across renders. The key only needs to be unique among its siblings. If the data has no natural stable identifier, the application may need to create one as part of establishing the item's identity rather than generating a new random value during every render.

What happens to component state when a key changes?

A changed key can cause React to treat the element as a different component instance. The previous instance can be removed and a new instance created, so local state does not carry over from the old keyed instance. This behavior is sometimes useful when deliberately resetting a component. It is also why unstable keys can unexpectedly reset state.