useId: Stable IDs That Survive SSR Hydration

Hands-on practice for this lecture. Work through the exercises and quizzes to reinforce what you've learned.

Exercise 1 of 1

useId & SSR Quiz

Three questions on ID generation in SSR apps — why Math.random breaks hydration, what useId guarantees, and the recommended suffix pattern.

interact to see yellow flashes

// Server renders: id="12345"
// Client hydrates: id="67890"
const id = Math.random().toString(36).slice(2);
return <label htmlFor={id}>Name <input id={id} /></label>;

What goes wrong here in a Next.js SSR app?

function FormField({ label }) {
  const id = useId();
  return (
    <>
      <label htmlFor={id}>{label}</label>
      <input id={id} />
    </>
  );
}

What guarantee does useId provide?

function MultiInput() {
  const id = useId();
  return (
    <form>
      <label htmlFor={id + "-name"}>Name</label>
      <input id={id + "-name"} />

      <label htmlFor={id + "-email"}>Email</label>
      <input id={id + "-email"} />
    </form>
  );
}

Is using one useId call with suffixes correct?

0/3 answered

💡 Never use Math.random(), Date.now(), or uuid() for element IDs in SSR apps. useId is the correct solution — it is deterministic, tree-position-based, and SSR-safe.

Re-read the lecture All lectures →