advanced · 23 minute study

Keys tell React which entity keeps its state

Index or random keys can move editable row state to the wrong item or reset it unexpectedly.

Loading progressEvidence grows with practice

Useful preparation · 1 prerequisite

Use this as a map, not a lock. If these ideas are familiar, continue.

A ref is a stable container; a render is a snapshot — Timers, DOM focus and async callbacks need deliberate decisions about current values, captured values and rendering.

First, build a mental model

React associates state with a component's identity in the render tree. A stable key helps distinguish siblings as their order changes.

Keys must be stable and unique among siblings.
Use entity IDs when available.
An array index describes a position, not necessarily an entity.
Changing a key deliberately resets that component's state; random keys do this accidentally on every render.

Read the codejsx · educational example

function PlayerList({ players }) {
  return players.map(player =>
    <EditablePlayer key={player.id} player={player} />
  );
}
// Risky when items reorder: key={index}
// Risky on every render: key={Math.random()}

Before reorder
Row state belongs to each keyed player.
After reorder
Stable keys let that state move with the player.
Changed key
A different identity causes a fresh component state.

Production thinking

Take this beyond the example.

Test row insertions, deletions, sorting and filtering with partially edited inputs. A static screenshot cannot reveal state-identity bugs.

Sources and further reading

Your evidence

unseen is a local learning signal, not a credential or proof of production competence.

Explain the mental model, then explicitly acknowledge it. Opening a page is not evidence.

Supported retries can complete this lesson. Independent evidence and delayed review determine the skill stage.

Next lesson · Measure work before caching it →