What problem does React's useId hook solve, and why are a module-level counter or Math.random() bad substitutes for it?

## The requirement Accessible markup depends on ids that connect elements: ```jsx <label htmlFor={id}>Email</label> <input id={id} aria-describedby={hintId} /> <p id={hintId}>We never share it.</p> ``` The ids must be unique on the page — two inputs with the same id break both the label association and any assistive technology that follows it — and, in a server-rendered app, they must be *the same string* in the HTML the server produced and in the first render the client performs while hydrating. Those two requirements together are what makes id generation harder than it looks. ## Why hydration is the hard constraint A server-rendered page is produced twice: once as HTML on the server, and once as a client render that attaches React to that HTML. Hydration assumes the two agree. If the server wrote `for="a1"` and the client's first render computes `for="b7"`, the attribute the browser sees no longer matches what React thinks it rendered, and the association is wrong even when the page looks fine. `useId` solves this by not generating randomness at all. React derives the id from where the component sits in the tree, and since the server and the client render the same tree, they derive the same string. Call the hook in a component and every instance gets its own value, because each instance has its own position. ```jsx import { useId } from 'react'; function EmailField() { const id = useId(); return ( <> <label htmlFor={id}>Email</label> <input id={id} type="email" /> </> ); } ``` Render `<EmailField />` three times and you get three distinct, hydration-stable ids with no bookkeeping. ## Why the usual substitutes fail **`Math.random()` / `crypto.randomUUID()` / `Date.now()`.** These are non-deterministic by design. The server produces one value, the client's hydration render produces another, and the markup mismatches on every single render. Some codebases hide this by generating the id in a `useState` initializer or a ref — that stabilises it *within* a client session but still differs from the server's value, so the hydration problem is untouched. **A module-level counter** (`let n = 0; const id = 'field-' + n++`). This looks deterministic and is not, for two reasons. It depends on how many other components incremented it first, which is a function of render order and can differ between the server pass and the client pass. And on a long-lived server the module is shared across requests, so the counter keeps climbing and two users get different ids for the same component — including ids that no client render will ever reproduce. **A hard-coded string** (`id="email"`). Deterministic, hydration-safe, and broken as soon as the component is rendered twice on one page: duplicate ids on a document are invalid and the label associates with whichever element the browser resolves first. **A prop passed down from the parent** is a legitimate option — the parent chooses the id and passes it in — but it pushes uniqueness bookkeeping onto every call site, which is exactly the chore `useId` removes. ## Properties of the returned value - It is a **string**, suitable for use directly in `id`, `htmlFor`, `aria-describedby`, `aria-labelledby` and similar attributes. - It is **stable across renders** of the same component instance, so it does not change when state updates. - Its **format is opaque**. React does not guarantee the shape of the string, and it has changed between React versions, so never parse it, never assume it is a valid bare CSS selector, and never construct one by string-concatenating it into a stylesheet. Use it as an attribute value. - It is **not a data identity**. It identifies a rendered position, not a record, so it is the wrong thing to persist, send to a server, or use as a React `key`. ## Multiple roots on one page When two independent React roots render into the same document, their generated ids could in principle collide. React exposes an `identifierPrefix` option on the root creation APIs (`createRoot` and `hydrateRoot`, and the server rendering APIs) so each root can namespace its ids. This is a real answer to a real problem, but it is worth mentioning only when the interviewer raises multi-root or micro-frontend setups — it is not part of everyday usage. ## How to answer Lead with the hydration requirement, since that is why the hook exists rather than a utility function. Then name the accessibility use case it serves, and dismiss random and counter-based approaches with the specific reason each fails: non-determinism for one, render-order and cross-request dependence for the other.