Hydration: visible first, interactive later
Simulated server: renderToString makes the HTML and we put it in the page by hand, as a server response would. hydrateRoot is real: it reuses the very same <button> element and only attaches the click handler.
Rendering strategies differ in where and when a page's HTML is made: in the browser (CSR), on the server for each request (SSR), once at build time (SSG), at build time and then refreshed (ISR), or on the server in pieces as data arrives (streaming); hydration then makes server HTML interactive.
Change the code and press Run (Ctrl+Enter). Predict what will happen first, then break it on purpose and read what changes. Your edits are saved and match the lesson page.
Ready for more? This phase has 5 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
Use renderToString to log the HTML for <Badge label="New" />, where Badge returns <span className="badge">{label}</span>.
Choose a strategy for each page of a news site: About page, an article, the live-scores widget, the logged-in reader's saved list. Give one reason each.
Explain it without notes
Compare CSR, SSR and SSG: where and when is the HTML made, and what are the costs of each?
What is hydration and why is a server-rendered page not interactive straight away?
How does streaming SSR with Suspense improve on plain SSR?
What is ISR and what does stale-while-revalidate mean?
Preview
Console
Nothing logged yet.Expected console output
Before hydration: Clicked 0 times
After hydration: Clicked 1 times
Same <button> element: true