A React list is rendered with key={crypto.randomUUID()} generated inside the render. What does the reconciler do on every re-render of that list, and why is this worse than keying by array index?

## What the reconciler sees The key is React's only handle on "which element is which". Generating it during render means the answer to that question is deliberately randomised every time. Trace the pairing: 1. The parallel walk compares the first new key with the first previous key. They differ (a fresh UUID never equals an old one), so the fast path stops at index 0. 2. React builds the map from *all* the previous children. 3. Every remaining new element is looked up and misses, so each one gets a brand-new fiber. 4. Nothing was ever claimed from the map, so every previous fiber is deleted. That is the worst possible outcome of the algorithm, reached on every single re-render — even one where the underlying data did not change at all. ## What it costs A delete-and-mount of the whole list, per render: - every host DOM node is destroyed and recreated, so uncontrolled input values, focus, text selection, scroll position inside rows and running CSS transitions are all lost; - every row's `useState`, `useReducer` and `useRef` values are discarded and re-initialised; - every effect in every row is cleaned up and re-run as a mount — including any data fetching, subscription or observer set up there; - refs are detached and re-attached, so anything imperative bound to those nodes is rebuilt. The symptom people report is a list that "flickers" or loses what the user typed whenever anything on the page updates. The mechanism is that nothing was ever reused. ## Why it is worse than an index key Index keys have real problems on insert, reorder and delete, but they are *stable across a render where nothing moved*. If the list did not change, index keys make the parallel walk succeed for every element and the entire reconciliation is a cheap in-place update. Random keys give up that path unconditionally: a re-render caused by something entirely unrelated still rebuilds the list. Ranked by how much identity information the reconciler gets: a stable id derived from the item is best; an index is a weak identity that is correct only while positions do not change; a fresh random value is *anti*-information, guaranteed wrong every time. ## The same bug in other clothing The pattern is not always as obvious as `Math.random()` or `crypto.randomUUID()`: ```jsx // all of these change on every render <Row key={Math.random()} /> <Row key={crypto.randomUUID()} /> <Row key={`${item.name}-${Date.now()}`} /> <Row key={JSON.stringify(item)} /> // changes whenever any field changes ``` The stringified-object key is the subtle one: it is deterministic, but it is a function of the item's *contents* rather than its identity, so editing one field of a row remounts that row and throws away its local state. A key must answer "which thing is this", not "what does this thing currently contain". ## Where a generated id is legitimate Generating an identifier is fine — generating it *during render* is not. If a client-created row genuinely has no server id yet, create the id once when the row is created (in the event handler that appends it) and store it on the item in state. From then on the key is read from the data and is stable for the row's lifetime, which is exactly what the reconciler needs. ## Answering well Describe the pairing failing completely — zero hits in the map, every previous fiber deleted — then list what a full remount costs, then make the comparison: index keys still let the parallel walk succeed when nothing moved, so they reuse fibers that random keys never do.