Discuss react-dom/server and apis available on it.
The react-dom/server APIs let you server-side render React components to HTML. These APIs are only used on the server at the top level of your app to generate the initial HTML. A framework may call them for you. Most of your components don’t need to import or use them.
- 1
renderToPipeableStream renders a React tree to a pipeable Node.js Stream.
- 2
These methods are only available in the environments with Node.js Streams:
- 1
renderToReadableStream renders a React tree to a Readable Web Stream.
- 2
These methods are only available in the environments with Web Streams, which includes browsers, Deno, and some modern edge runtimes:
- 1
renderToString renders a React tree to a string.
- 2
renderToStaticMarkup renders a non-interactive React tree to a string.
- 3
These methods can be used in the environments that don’t support streams
- 4
They have limited functionality compared to the streaming APIs.
Scenario Questions
0-2 years experience
- 1We have a marketing landing page that needs to load instantly and doesn't need any React interactivity. Which react-dom/server API would you use to generate the HTML, and what happens if we accidentally try to use React state or event listeners inside those components?
- 2You've set up a basic Express server to render your React app using renderToString. When the page loads in the browser, you notice a flash of content and a console warning about a markup mismatch. How would you go about finding what caused this mismatch?
2-5 years experience
- 1Our team is migrating a dashboard from renderToString to React 18's renderToPipeableStream to improve Time to First Byte (TTFB). During testing, we noticed that some components that fetch data on the client are now breaking the stream. How would you structure the component tree and use Suspense to ensure slow components don't block the initial HTML shell?
- 2Imagine we have a component that displays the current time or a localized currency symbol. When we render this on the server and hydrate it on the client, we keep getting hydration errors because the values don't match. How would you refactor this component to safely handle server-side rendering without triggering these errors?
5-8 years experience
- 1We are experiencing high CPU utilization and event loop lag on our Node.js SSR servers during peak traffic. The profiler points to renderToString as the main culprit. Walk me through how you would redesign our rendering pipeline to mitigate this, and what architectural changes we'd need to make to our hosting environment.
- 2Suppose a deeply nested component throws an error during the server-side render phase. With renderToString, this crashes the entire render. How does React 18's streaming API handle server-side errors differently, and how would you design our error boundary and fallback strategy to ensure the user still gets a functional page?
8+ years experience
- 1We are planning to migrate a large-scale, multi-tenant e-commerce platform from a traditional client-side SPA to a hybrid streaming SSR architecture deployed at the Edge (e.g., Cloudflare Workers). What are the architectural implications of moving from Node.js-specific APIs to renderToReadableStream, and how would you address global state hydration and dependency sharing across micro-frontends in this setup?
- 2Our organization has a mix of legacy React 16/17 apps and newer React 18 apps. We want to establish a unified platform-level SSR service. What are the trade-offs of forcing a single streaming SSR standard versus supporting legacy synchronous rendering, and how would you design the migration path to minimize developer friction across 50+ engineering teams?
Follow-up Questions
- How does React handle a Suspense boundary that times out or fails on the server?
- What is the difference between renderToPipeableStream and renderToReadableStream in terms of target environments?
- How do you pass server-side fetched data to the client safely to avoid double-fetching during hydration?