Chapter 109: React DOM Static — Prerender APIs

Core Idea

prerender/prerenderToNodeStream generate complete static HTML upfront (waiting for all data, unlike streaming SSR's incremental delivery), while resumeAndPrerender/resumeAndPrerenderToNodeStream let that static output later be "resumed" with fresh per-request data — the toolkit for static-site-generation-style rendering combined with selective dynamic completion.

Key Concepts

• prerender(reactNode, options): unlike renderToReadableStream (Ch 107), this waits for the entire tree (including all Suspense boundaries) to finish before resolving — appropriate for build-time static generation, where you want one complete, cacheable HTML output rather than a stream that starts before everything's ready.
• prerenderToNodeStream(reactNode, options): the Node-stream-returning variant of prerender, for Node-based static-generation build tooling.
• resumeAndPrerender(reactNode, postponedState, options) / resumeAndPrerenderToNodeStream(...): continue a previously-postponed prerender (Ch 108's postponedState concept) and produce a new, complete prerendered result — the mechanism for combining a mostly-static prerendered shell with request-specific dynamic data filled in later, still producing full (non-streamed-to-the-browser) HTML rather than an incremental stream.
• Static vs. streaming trade-off: prerender APIs trade "the client sees nothing until everything is ready" for "the output is a single, complete, cacheable HTML document" — the opposite trade-off from the streaming SSR APIs (Ch 106-107), which prioritize fast Time to First Byte over completeness at first paint.
• Framework-level usage: these APIs are primarily consumed by static-site-generation tooling inside frameworks (build-time page generation) rather than called directly in typical application code.

Key Takeaways

1. Reach for the prerender family when you need one complete, cacheable HTML artifact (build-time SSG) rather than a progressively-streamed response.
2. resumeAndPrerender* is specifically for continuing a postponed prerender with fresh data — not a general "retry a failed render" mechanism.
3. Most application developers interact with these indirectly, through a framework's static-generation build step, rather than calling them directly.

Connects To

• Ch 108 (Server Static & Resume APIs): the postponedState concept both resume and resumeAndPrerender build on.
• Ch 106-107 (renderToPipeableStream / renderToReadableStream): the streaming-first alternative with the opposite completeness/speed trade-off.