You render a React list from an API response whose items have no id field. What do you use as the key, and why is `key={crypto.randomUUID()}` written inline in the JSX the wrong answer?

## The ladder **1. A natural key in the payload.** Plenty of "no id" responses have one anyway: `email` for a user, `sku` or `isbn` for a product, `slug` for an article, `date` for a per-day row, `symbol` for a ticker. Ask whether the field is unique in this collection and whether it can change while the row is on screen. An email is a decent key until your app lets people edit their email, at which point the row remounts on save. **2. A composite key.** When no single field is unique, combine the ones that are jointly unique: ```jsx {entries.map((e) => ( <Row key={`${e.userId}-${e.date}`} entry={e} /> ))} ``` Be explicit about the separator so that `12`+`3` and `1`+`23` cannot collide, and pick fields that are part of the row's identity rather than its content. Hashing the whole object (`JSON.stringify(row)`) is the tempting shortcut and is wrong: the key then changes whenever any field is edited, so editing a row remounts it. **3. Mint an id at the boundary.** If the data has no identity at all, give it one exactly once, where the data enters the app: ```js const withIds = (await res.json()).map((row) => ({ id: crypto.randomUUID(), ...row, })); setRows(withIds); ``` Now the id lives in state alongside the row and is stable for the item's whole lifetime. The same applies to items the user creates locally: assign the id in the event handler or reducer that appends the row, not in the component that renders it. ## Why generating in render is a bug Render runs many times — on every state change in this component or an ancestor, and in development React may render again to surface impure code. A key computed during render is therefore a *different value every time*: ```jsx {rows.map((row) => <Row key={crypto.randomUUID()} row={row} />)} // never do this ``` Every new key is absent from the previous children and every old key is absent from the new ones, so React's conclusion is that the entire list was removed and a completely different list was added. The consequences: - every `Row` instance is unmounted and a fresh one mounted, so all local state resets and every mount effect re-runs — including any per-row fetch; - every DOM node is destroyed and rebuilt, so focus is lost mid-typing, uncontrolled input values vanish, scroll position resets and CSS transitions restart; - you pay maximum DOM cost on every single render, which is exactly the opposite of what keys are for. `Math.random()`, `Date.now()` and a module-level counter incremented in render all fail the same way, and they additionally make render impure, which breaks the assumptions React relies on to render safely. ## When the index is acceptable The index is a valid key only under a narrow contract: the list is never sorted, filtered, or inserted into except at the end; items are never removed from the middle; and the rows hold no state React does not rewrite from props — no uncontrolled inputs, no local `useState`, no focus or animation that has to follow the item. A hardcoded nav array, a static legend, a read-only table that is replaced wholesale — fine. Write it down as a comment if you rely on it, because the contract is invisible and the next person adds sorting. ## Deciding, in practice A short checklist you can say out loud: 1. Is there a field that identifies the row and does not change while it is displayed? Use it. 2. Can I make one from two or three such fields? Use a composite with an explicit separator. 3. Otherwise, where does this data enter the app? Add an id there and store it. 4. Only if the list is provably static and stateless, fall back to the index. 5. Never compute the key during render. ## The upstream conversation Worth saying at senior level: "the API returns rows with no identity" is usually a data-modelling gap, not a rendering problem. Client-side ids are invisible to the server, so they cannot survive a refetch — a refetched list gets brand-new ids and remounts. If the list is editable, paginated, or reconciled against server updates, the durable fix is to ask for a stable id in the response rather than to keep patching identity in the view layer.