In React, does a key have to be unique across the whole page, and can the child component read the value you passed as its key?

## Keys are scoped to siblings When React reconciles children it compares the new children of *one parent* with the old children of *that same parent*. Keys are only ever compared inside that set. Concretely: ```jsx function Board({ todo, done }) { return ( <> <ul>{todo.map((t, i) => <li key={i}>{t.text}</li>)}</ul> <ul>{done.map((d, i) => <li key={i}>{d.text}</li>)}</ul> </> ); } ``` Both lists use `0, 1, 2`. That is not a collision, and React does not warn, because the two arrays live under different parents. (The index keys here are a separate problem — see list-mutation behaviour — but the *duplication across lists* is not one.) The same applies to nesting: a list of groups where each group renders its own list of members needs the group keys unique among groups, and the member keys unique only within their own group. A member id repeated across two groups is harmless. What *is* a real error is a duplicate inside one list. React logs `Encountered two children with the same key` and the pairing becomes ambiguous, so state can appear to leak between the two rows or one of them can be dropped. When your natural id is not unique per list — the same product appearing in two line items, say — build a composite key from fields that together are unique, or deduplicate upstream. Globally unique keys (UUIDs, database ids) are perfectly fine and usually what you have anyway. The point is that uniqueness beyond the sibling set buys you nothing, so "my ids collide across lists" is not a reason to invent prefixed keys. ## `key` is not a prop JSX attribute syntax makes `key` *look* like a prop, but React treats it specially. When an element is created, `key` (and, historically, `ref`) is pulled out and stored on the element itself, not in its props object. So inside the component: ```jsx function Row(props) { console.log(props.key); // undefined return <li>{props.label}</li>; } ``` `props.key` is `undefined`. React 19 additionally warns when you try to read `key` off a props object, precisely because people assume it is there. The fix is to pass the identifier twice when the child genuinely needs it: ```jsx {rows.map((row) => ( <Row key={row.id} id={row.id} label={row.label} /> ))} ``` That looks redundant and is not: one is React's identity for reconciliation, the other is data your component uses (to build a DOM `id`, to send a delete request, to look the record up). The mirror-image mistake is spreading a data object straight into JSX when that object happens to contain a `key` field: ```jsx <Row {...row} /> // row.key silently becomes the element's key ``` React 19 warns about a props object containing a `key` being spread into JSX, because the behaviour is surprising in both directions — a data field quietly becomes reconciliation identity, and it does not arrive as a prop. Pass the key explicitly and spread the rest. ## What a key may be A key is coerced to a string, so strings and numbers are the practical choices. Objects are not usable as keys — unlike a `Map`, React does not key by reference identity, and an object would stringify to something useless. Booleans, `null` and `undefined` are not valid identities either; `key={undefined}` behaves as if you had written no key at all, which is a common accident when the id field is missing from some records. Keys must also be stable: the same item must produce the same key on every render for the whole time it is in the list. ## Why this matters in interviews The two facts test the same understanding from opposite sides: a key is a *message to React about identity*, not a piece of the component's data and not a page-wide registry. Candidates who think keys are global invent prefixing schemes that add noise; candidates who think keys are props write components that read `undefined` and quietly break. Saying "scoped to siblings, consumed by React, pass the id separately if you need it" covers both in one breath.