In a Vue 3.5 SSR app, why should a form component generate its label and input ids with useId() instead of Math.random() or a counter?

## Why ids are a hydration problem Accessible forms need ids: `<label for>` must match an `<input id>`, and `aria-describedby` must point at a hint element's `id`. In a server-rendered Vue 3 app these attributes are produced **twice**, once into the server HTML and once by the client render that hydrates it. Hydration expects the two to agree. Anything that generates ids from state outside the component tree breaks that expectation. ### `Math.random()` or `crypto.randomUUID()` Different on every call, so the server's id and the client's id always differ. In development, Vue reports an **attribute mismatch** on the element. ### A module-level counter ```ts let next = 0 export const makeId = () => `field-${next++}` ``` This looks deterministic but is not: - The **server** loads the module once and keeps it for its whole life, so the counter keeps rising across every request, including concurrent ones. - Each **browser** loads the module fresh and starts at `0`. The first visitor after a deploy may get matching ids; everyone after that gets mismatches. (Module state shared between requests is a broader SSR hazard in its own right.) ## What an attribute mismatch actually does Vue's attribute, class and style mismatch warnings end with a note that the mismatch is **check-only**: the DOM will not be rectified in production because of the performance cost. In practice, attributes that Vue patches as declared dynamic props may still receive the client value, while others keep the server value, and in production without the details flag Vue does not even check them. The result you cannot rely on: code that later queries `document.getElementById(id)` or builds an `aria-*` reference from the client-side id may not find what the DOM contains. The only safe design is an id that is the same on both sides. ## How `useId()` solves it `useId()` was added in **Vue 3.5**, together with `app.config.idPrefix`. In the 3.5 source it: 1. reads the **current component instance** (so it must be called during `setup`); 2. starts from `app.config.idPrefix`, or `v` when none is set; 3. appends counters that live on the component instance tree, incremented per call. Because the server and the client render the same tree in the same order, the n-th call in a given component produces the same string on both sides. Key properties: - **Unique per application:** several calls in one component give different ids, and several instances of the same component give different ids. - **Async-safe:** components with async `setup()`, components with `serverPrefetch`, and async components start a new sub-prefix, so the order in which async work resolves does not reshuffle ids. - **Selector-safe:** generated ids can be used in CSS selectors. ## Rules of use | Situation | What to do | |---|---| | Normal component | `const id = useId()` at the top level of `<script setup>` | | Several related ids | derive them: `` `${id}-hint` ``, `` `${id}-error` `` | | Items in a `v-for` | combine one `useId()` with each item's own stable key | | Two Vue apps on one page | give each a distinct `app.config.idPrefix` | | Inside `computed()` | do not call it there; the docs warn it can cause instance conflicts | | Outside any component | it returns an empty string and warns in development | ## What `useId()` does not cover - Ids that must be **stable across page loads** or meaningful to outside systems (analytics, deep links): use data from your domain instead. - Ids for components created **outside** the rendered tree: without an active instance, `useId()` has nothing to derive from.