Context misuse & key-as-index

Anti-pattern A: context whose value changes often re-renders every consumer, no matter how deep. A context Provider re-renders all consumers whenever its value changes identity. Put high-frequency state — a controlled input, a mouse position, a timer — in a wide context and every consumer in the subtree re-renders on every keystroke or frame. The “convenience” of not threading a prop becomes a tree-wide render storm.

// Anti-pattern: form draft (changes on every keystroke) shared app-wide
const AppContext = createContext<{ draft: string; setDraft: (s: string) => void } | null>(null);

function App() {
  const [draft, setDraft] = useState("");
  // every keystroke → new value object → EVERY consumer re-renders
  return (
    <AppContext.Provider value={{ draft, setDraft }}>
      <Header />   {/* re-renders on each keystroke */}
      <Sidebar />  {/* re-renders on each keystroke */}
      <Editor />   {/* the only thing that actually needs draft */}
    </AppContext.Provider>
  );
}

It passes a demo because three cheap children re-rendering is invisible. In production, those children are expensive trees, and the typing lags.

The fix is scope, not avoidance: keep high-frequency or purely-local state out of wide context — colocate it, or split context by change-frequency. If only Editor needs the draft, that state belongs in Editor (or its nearest shared parent), not the app root. When state genuinely is shared but mixes stable and volatile data, split it: a rarely-changing context (theme, user) stays wide; the volatile slice gets its own narrow provider, or moves out entirely. Also remember a fresh value={{ ... }} object each render is itself a re-render trigger — memoize it when the context legitimately stays wide.

// Fix: the draft lives where it's used; context carries only stable, shared data
const ThemeContext = createContext<Theme>("light"); // changes rarely → safe to be wide

function App() {
  const theme = useTheme();
  return (
    <ThemeContext.Provider value={theme}>
      <Header />
      <Sidebar />
      <Editor /> {/* owns its own draft useState — no tree-wide churn */}
    </ThemeContext.Provider>
  );
}

Scope each piece of state to exactly who needs it. Context is for shared state, and works best when that shared state changes infrequently.

Anti-pattern B: key={index} ties a component’s identity to its position, so any reorder/insert/delete makes React reuse the wrong instance. Keys tell React which element is which across renders. With index keys, “the item at position 0” is always key 0 — so if you prepend, insert, or sort, React thinks the new item at position 0 is the same element as before and keeps the old component’s internal state (input text, focus, selection, scroll, a checkbox) attached to the wrong data.

// Anti-pattern: index keys on a list the user can reorder / add to
{todos.map((todo, i) => (
  <li key={i}>
    {todo.label}
    <input defaultValue={todo.note} /> {/* uncontrolled state lives in the DOM node */}
  </li>
))}
// Prepend a todo → every note input now shows the PREVIOUS row's text.

Static, never-reordered lists survive index keys, which is exactly why this slips through review — the bug is dormant until the list mutates.

The fix is stable identity: key by a value that travels with the item — a server id or a generated id created when the item is born, never the array index, and never Math.random(). A stable key means React keeps each component glued to its own data through any reorder, so input text, focus, and selection follow the right row. The two over-corrections both fail: key={Math.random()} produces a new key every render, so React remounts every row on every render (state lost, focus lost, worst case). And key={JSON.stringify(item)} re-keys whenever any field changes, remounting on edit.

// Fix: a stable id that belongs to the item
{todos.map((todo) => (
  <li key={todo.id}>{todo.label}<input defaultValue={todo.note} /></li>
))}
// If the source has no id, mint one at creation time, not at render time:
const addTodo = (label: string) =>
  setTodos((t) => [...t, { id: crypto.randomUUID(), label, note: "" }]);

Index keys are acceptable only when the list is static, never reordered/filtered, and items have no identity and no internal state — a frozen menu, not a user-editable list.