Keys and Reconciliation in React

Keys let React identify sibling elements across renders so it can preserve the correct component instances and their state. Stable keys make list updates predictable, especially when items are inserted, removed, or reordered.

When React renders a list, each sibling needs a `key` that identifies it among its siblings. During reconciliation, React uses keys along with element type to determine which existing elements correspond to the new elements.

A stable key should represent the identity of the underlying item, such as a database ID. If an item keeps the same key across renders, React can associate it with the same component instance and preserve its state when appropriate.

Using an array index as a key is risky when the list can change order, have items inserted, or have items removed. After such a change, an index can refer to a different item, causing component state or DOM-related behavior to appear attached to the wrong item.

Keys only need to be unique among their immediate siblings. They do not need to be globally unique across the application, and changing a component's key intentionally causes React to treat it as a different instance.

Key points

• Use stable, item-specific keys when rendering dynamic lists.
• Keys help React match elements between renders.
• Avoid array indexes as keys when items can be reordered, inserted, or deleted.
• Keys are scoped to sibling elements.
• Changing a key causes React to replace the associated component instance rather than preserve it.

Interview questions

Why does React need keys when rendering a list?

React needs a way to match elements in the new render with elements from the previous render. A key provides identity among siblings, allowing React to determine which items correspond across renders. This helps React preserve the appropriate component instances and their state. Without suitable keys, list updates can produce inefficient or incorrect reconciliation behavior.

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

An array index describes an item's current position rather than its identity. If an item is inserted, removed, or moved, the same index can become associated with a different item. React may then reuse a component instance for the wrong data, which can make local state appear to move between rows. Index keys are therefore safest only when the list is effectively static and never reordered or structurally changed.

Where must keys be unique?

Keys must be unique among the siblings in the collection being reconciled. They do not have to be globally unique throughout the application. Two separate lists can use the same key values without conflict if the elements are in different sibling sets. The important requirement is that React can distinguish the relevant siblings within their parent context.

What happens when a component's key changes between renders?

React uses the key as part of the element's identity during reconciliation. If the key changes, React does not treat the new element as the same keyed instance. The old instance can be removed and a new instance created, so local state associated with the old instance is not preserved in the new one. This behavior can be useful when you intentionally want to reset a component.

How would you choose a key for a list of database records?

I would normally use a stable identifier supplied by the record, such as its database ID. The identifier should remain associated with the same logical item across renders. I would avoid generating a random value during rendering because that changes identity on every render. If records lack stable IDs, I would consider whether the data model can provide one before falling back to a position-based key.