React Component Identity and Remounting

React preserves or resets component state according to a component’s identity in the rendered tree. Identity is primarily determined by the element type, its position among siblings, and its `key`, so changing identity can cause a remount and loss of local state.

React does not treat a component instance as identical merely because the same JSX-looking component appears again. During reconciliation, React matches elements in the current tree with elements from the previous render. The match determines whether an existing component instance can be updated or whether a new instance must be created.

For siblings, `key` is the explicit identity mechanism. A stable key lets React associate an item with the same component instance even when its position changes. Without an appropriate key, inserting, deleting, or reordering children can cause React to associate state with the wrong item or recreate parts of the tree.

Changing a component's `key` forces React to treat the element as a different identity. The old instance is unmounted and a new one is mounted, so its local state and other instance-specific state are initialized again. This can be useful deliberately, such as resetting a form when switching between records.

Element type also matters. Replacing one component type with another at the same location does not preserve the old component's state as though it were the same instance. Conversely, rendering the same component type in a stable tree position generally allows React to preserve its state across renders.

A senior engineer should distinguish state preservation from DOM preservation. React may update an existing host element without remounting its component, while a component remount means a new component instance is created and mount-related lifecycle behavior occurs again. Keys should therefore express stable identity, not simply suppress warnings or encode a transient array position.

Key points

• State is associated with component identity in the rendered tree, not with the JSX function call alone.
• Changing `key` changes identity and can force a component to remount and reset local state.
• Stable keys are essential when sibling items can be inserted, deleted, or reordered.
• Changing an element or component type can cause React to replace the previous instance rather than preserve its state.
• Using array indexes as keys can associate existing state with a different logical item after reordering or insertion.

Interview questions

Why does changing a component's `key` reset its state?

A key participates in the identity React uses when reconciling siblings. If the key changes, React no longer treats the new element as the same component instance. The previous instance is removed and a new instance is created. The new instance therefore starts with its initial state rather than inheriting the previous instance's local state.

What determines whether React preserves a component's state between renders?

React compares the new rendered tree with the previous one and attempts to match corresponding elements. The element type and position in the tree matter, while `key` provides explicit identity among siblings. When React considers the element the same identity, its component state can be preserved. When identity changes, React can remove the old instance and create a new one.

Why can using an array index as a key cause bugs?

An array index identifies a position rather than the underlying logical item. If an item is inserted, removed, or moved, the same index can refer to a different item on the next render. React may then preserve the component state associated with that position and attach it to the wrong data. A stable identifier belonging to the item is generally safer when the list can change order or membership.

How would you deliberately reset a form when switching between records?

I would give the form component a key derived from the record's stable identifier, such as `key={userId}`. When the record changes, the key changes and React treats the form as a new component instance. That resets its local state and reruns mount-related behavior for the new instance. I would use this only when a full reset is intended, because it also discards any unsaved local state from the previous record.

A component moves to another position in a list. When can React preserve its state?

For siblings, React uses keys to associate an element with its logical identity across renders. If the component keeps the same stable key, moving it can allow React to preserve its state despite the changed position. If keys are absent or unstable, React may instead match elements by position and associate state with the wrong item. The important distinction is stable identity versus current position.