How to Preserve and Reset State with Component Keys

To preserve and reset state with component keys, give a component a key that changes when its identity changes. React ties state to a position in the render tree, not to the component itself. A different key moves the component to a new position with fresh state.

State lives in a position

React does not store state inside the component function. It associates each piece of state with a position in the render tree, and the same component at the same position keeps its state across re-renders.

That is why two counters rendered side by side stay independent. Each one has its own position, so each one has its own score, even though both come from the same Counter definition. The position is the address; the component is just the blueprint.

Changing a prop also leaves state alone. The component is still in the same spot, so only the prop changes while the state survives. This is the behavior a key can override.

When React preserves state

React preserves state for as long as the same component type renders at the same position. Two situations reset state automatically.

• A different component type appears at the same position.
• The component is removed from the tree entirely.

A conditional that swaps a Counter for a paragraph destroys the Counter's state, because the paragraph is a different component in that position. Removing the component and adding it back also starts its state from scratch. The reverse is also true: keeping the same type and position preserves state, no matter how the props change.

Reset state with a changing key

To reset a component without moving it in the tree, give it a key. A different key tells React this is a different component, so it unmounts the old one and mounts a fresh one.

App.jsx

function Scoreboard() {
  const [person, setPerson] = useState("Taylor");
  function nextPlayer() {
    setPerson(person === "Taylor" ? "Sarah" : "Taylor");
  }
  return <Counter key={person} person={person} />;
}

When person changes, the key changes too, so React throws away the old Counter and creates a new one. The score resets to zero on every switch, which is what a two-player scoreboard should do.

The same idea resets a form when the user switches contacts. Resetting state covers the setter-based alternative for cases where the component should stay mounted.

Reset a form when the contact changes

A chat form is the same pattern. When the user switches from Alice to Bob, the draft text must not carry over to the wrong person.

App.jsx

<Chat key={to.id} contact={to} />

Giving the Chat component a key based on the recipient remounts it on every switch. The input starts empty for each contact, so a message meant for Alice can never be sent to Bob by accident.

Keys are scoped to the parent

A key does not have to be globally unique. It only identifies a position among the siblings of the same parent, so two different lists can reuse the same key values without conflict.

Keys are also how React keeps list items straight when a list reorders. The lists guide explains that half, while this article uses keys to control state identity.

Common mistakes

• Nesting a component definition inside another resets its state on every render.
• Using the index as a key breaks state when the list reorders or filters.
• Moving a component to a different position without a key resets it unexpectedly.

State is position-based, so the fix is almost always to make the position or the key match the identity you actually care about. When state resets unexpectedly, look at the tree position first, then at the key, before touching the component.

What to learn next

Keys connect back to how state itself works, so the useState guide is worth a revisit once the position model clicks.