A React comment editor is rendered as <CommentBox key={draftText} authorId={authorId} /> so that it clears when the author changes, and now the textarea loses focus after every keystroke. What is wrong with that choice of key value, and what should it be instead?

## What a reset key means When you use `key` to reset state, you are telling React "this component instance exists for exactly one thing; when that thing changes, throw the instance away." The value you pass is therefore a claim about identity. Everything follows from taking that literally: if the value changes, React believes the identity changed, and it is right to destroy the subtree. ## Why keying on content thrashes `key={draftText}` says the editor's identity *is* its text. The user types one character, the key changes, and React does what it was told: unmount, mount fresh. The consequences on every keystroke are: - the `<textarea>` DOM node is removed and recreated, so focus and the caret position are lost; - state inside resets, which usually means the character is lost too and typing feels broken; - mount effects re-run and their cleanups fire, so subscriptions, timers and any request started on mount cycle repeatedly; - CSS transitions and animations restart from the beginning. The same failure appears with any value derived from mutable data: `key={record.title}` while the title is being edited, `key={items.length}`, `key={JSON.stringify(filters)}` where filters include live input, or `key={Date.now()}`. The worst variant is `key={Math.random()}`, which produces a new identity on literally every render, so the component can never hold state at all. ## What to key on instead Pick the most stable value that changes exactly when the component should start over: ```jsx <CommentBox key={authorId} authorId={authorId} /> ``` Good key values share three properties. They are **stable** — the same across re-renders while the identity is unchanged. They are **primitive** — a string or number, because React compares keys as strings; passing an object gives you the same stringified value for every object, so it never changes and never resets. And they are **meaningful** — a server id, a slug, a route param, a composite of those. For composite identity, join stable parts explicitly: ```jsx <Editor key={`${orgId}:${documentId}`} documentId={documentId} /> ``` That is honest about the fact that switching organisation *or* document should start a fresh editor. ## Deliberate remounts are the exception There is one legitimate case where the key value is not an identity: forcing a reset on demand. A counter incremented by a "Start over" button — `key={resetCount}` with `setResetCount(n => n + 1)` — is a clear way to blow away a subtree that has no better handle. It reads as intentional because the value changes only when a user action says so, never as a side effect of typing or fetching. Use it sparingly; a reset action inside the component is usually easier to reason about, and the counter is best when the state to clear is spread across a whole subtree you do not own. ## Diagnosing it in the wild The signature symptoms of a bad reset key are: an input that loses focus while typing, a component whose mount effect appears to run constantly, an animation that never completes, and a scroll container that snaps back. In React DevTools, the component shows up as a fresh instance rather than an updating one, and its state is always at its initial value. If you see any of those, look at the key expression first and ask whether the value it computes can change while the component is legitimately alive. ## The one-line rule Key on the identity of the thing, not on the data about it. If you cannot say out loud "this key changes only when the component should start over from scratch," the expression is wrong.