In a React app, two unrelated lists on the same page each give their rows the key values 1, 2 and 3. Is that a problem? Explain the scope in which React actually compares keys.

## What a key names When React renders `<Row key="a" />`, the key is stored on the element and then on the fiber React creates for it. It is not registered anywhere global. Reconciliation runs parent by parent: when a parent re-renders, React takes the new child list it just produced and pairs it against the child list that *same* parent produced on the previous render. To do that it builds a lookup table from the previous children, keyed by their keys. That table contains that one parent's previous children and nothing else. So a key is a name that is valid inside one child list, for the duration of one pairing. "Unique keys" in the React warning always means unique among siblings. ## Consequence 1: reuse across lists is free ```jsx <ul>{users.map((u, i) => <li key={i}>{u.name}</li>)}</ul> <ul>{tags.map((t, i) => <li key={i}>{t}</li>)}</ul> ``` Both lists use the keys `0, 1, 2`. There is no collision, because the two `<ul>` elements are separate parents with separate child sets. You never need to prefix keys with the list name to make them globally unique. (Whether index keys are a good choice at all is a different question — that is about stability across renders, not about scope.) ## Consequence 2: duplicates inside one list are the real bug If one child set contains two elements with the same key, React logs `Encountered two children with the same key`. The pairing is ambiguous: a given previous fiber can be matched at most once, so the second element with that key finds nothing to pair with and is mounted fresh. In practice that shows up as a row that silently loses its state, or updates landing on the wrong row. The fix is to make the key derive from something actually unique in that list — a compound key such as `` `${item.type}-${item.id}` `` when two collections are concatenated into one list. ## Consequence 3: a key cannot move state between parents This is the part candidates get wrong. Consider a row that moves from an "Active" list to an "Archived" list, keeping `key={row.id}`: ```jsx <ul>{active.map(r => <Row key={r.id} row={r} />)}</ul> <ul>{archived.map(r => <Row key={r.id} row={r} />)}</ul> ``` When the row moves, the first `<ul>` reconciles its children and finds no element for that key, so it deletes that fiber — running its effect cleanups and detaching its refs. The second `<ul>` reconciles its own children and finds a key it has never seen, so it mounts a brand-new fiber with fresh hook state. The identical key value is irrelevant: the two parents never look at each other's children. Component state survives a move only inside one parent's child list. ## Consequence 4: key is not a prop React consumes `key` itself; it is not passed through to the component, so a component cannot read `props.key`. If the child needs its identifier, pass it a second time as an ordinary prop: ```jsx <Row key={row.id} id={row.id} /> ``` ## Keys are strings React coerces a key to a string, so `key={1}` and `key="1"` are the same key. That matters when a list mixes numeric ids with string ids that happen to stringify identically — those count as duplicates, warning and all. ## The shape of a good answer Say that the comparison is per-parent, that the lookup is built only from that parent's previous children, and then draw the two consequences: cross-list reuse is harmless, and a shared key across parents preserves nothing. That demonstrates you know where the matching happens, not just that keys "help React".