API Reference
Server APIs

renderToPipeableStream

Reference

renderToPipeableStream(reactNode, options?)

Call renderToPipeableStream to render your React tree as HTML into a

On the client, call to make the server-generated HTML interactive.

Parameters

  • reactNode: A React node you want to render to HTML. For example, a JSX element like <App />. It is expected to represent the entire document, so the App component should render the <html> tag.

  • optional options: An object with options.

    • optional bootstrapScriptContent: If specified, this string will be placed in an inline <script> tag.
    • optional bootstrapScripts: An array of string URLs for the <script> tags to emit on the page. Use this to include the <script> that calls Omit it if you don’t want to run React on the client at all.
    • optional bootstrapModules: Like bootstrapScripts, but emits instead.
    • optional identifierPrefix: A string prefix React uses for IDs generated by Useful to avoid conflicts when using multiple roots on the same page. Must be the same prefix as passed to
    • optional namespaceURI: A string with the root for the stream. Defaults to regular HTML. Pass 'http://www.w3.org/2000/svg' for SVG or 'http://www.w3.org/1998/Math/MathML' for MathML.
    • optional nonce: A string to allow scripts for .
    • optional onAllReady: A callback that fires when all rendering is complete, including both the and all additional You can use this instead of onShellReady If you start here, you won’t get any progressive loading. The stream will contain the final HTML.
    • optional onError: A callback that fires whenever there is a server error, whether or By default, this only calls console.error. If you override it to make sure that you still call console.error. You can also use it to before the shell is emitted.
    • optional onShellReady: A callback that fires right after the has been rendered. You can and call pipe here to start . React will after the shell along with the inline <script> tags that replace the HTML loading fallbacks with the content.
    • optional onShellError: A callback that fires if there was an error rendering the initial shell. It receives the error as an argument. No bytes were emitted from the stream yet, and neither onShellReady nor onAllReady will get called, so you can
    • optional progressiveChunkSize: The number of bytes in a chunk.

Returns

renderToPipeableStream returns an object with two methods:

  • pipe outputs the HTML into the provided Call pipe in onShellReady if you want to enable , or in onAllReady for crawlers and static generation.
  • abort lets you and render the rest on the client.

Usage

Rendering a React tree as HTML to a Node.js Stream

Call renderToPipeableStream to render your React tree as HTML into a

Along with the root component, you need to provide a list of bootstrap <script> paths. Your root component should return the entire document including the root <html> tag.

For example, it might look like this:

React will inject the and your bootstrap <script> tags into the resulting HTML stream:

On the client, your bootstrap script should

This will attach event listeners to the server-generated HTML and make it interactive.

Deep Dive

Reading CSS and JS asset paths from the build output

The final asset URLs (like JavaScript and CSS files) are often hashed after the build. For example, instead of styles.css you might end up with styles.123456.css. Hashing static asset filenames guarantees that every distinct build of the same asset will have a different filename. This is useful because it lets you safely enable long-term caching for static assets: a file with a certain name would never change content.

However, if you don’t know the asset URLs until after the build, there’s no way for you to put them in the source code. For example, hardcoding "/styles.css" into JSX like earlier wouldn’t work. To keep them out of your source code, your root component can read the real filenames from a map passed as a prop:

On the server, render <App assetMap={assetMap} /> and pass your assetMap with the asset URLs:

Since your server is now rendering <App assetMap={assetMap} />, you need to render it with assetMap on the client too to avoid hydration errors. You can serialize and pass assetMap to the client like this:

In the example above, the bootstrapScriptContent option adds an extra inline <script> tag that sets the global window.assetMap variable on the client. This lets the client code read the same assetMap:

Both client and server render App with the same assetMap prop, so there are no hydration errors.

more content as it loads

allows the user to start seeing the content even before all the data has loaded on the server. For example, consider a profile page that shows a cover, a sidebar with friends and photos, and a list of posts:

Imagine that loading data for <Posts /> takes some time. Ideally, you’d want to show the rest of the profile page content to the user without waiting for the posts. To do this,

This tells React to start the HTML before Posts loads its data. React will send the HTML for the loading fallback (PostsGlimmer) first, and then, when Posts finishes loading its data, React will send the remaining HTML along with an inline <script> tag that replaces the loading fallback with that HTML. From the user’s perspective, the page will first appear with the PostsGlimmer, later replaced by the Posts.

You can further to create a more granular loading sequence:

In this example, React can start the page even earlier. Only ProfileLayout and ProfileCover must finish rendering first because they are not wrapped in any <Suspense> boundary. However, if Sidebar, Friends, or Photos need to load some data, React will send the HTML for the BigSpinner fallback instead. Then, as more data becomes available, more content will continue to be revealed until all of it becomes visible.

does not need to wait for React itself to load in the browser, or for your app to become interactive. The HTML content from the server will get progressively revealed before any of the <script> tags load.

Specifying what goes into the shell

The part of your app outside of any <Suspense> boundaries is called the shell:

It determines the earliest loading state that the user may see:

If you wrap the whole app into a <Suspense> boundary at the root, the shell will only contain that spinner. However, that’s not a pleasant user experience because seeing a big spinner on the screen can feel slower and more annoying than waiting a bit more and seeing the real layout. This is why usually you’ll want to place the <Suspense> boundaries so that the shell feels minimal but complete—like a skeleton of the entire page layout.

The onShellReady callback fires when the entire shell has been rendered. Usually, you’ll start then:

By the time onShellReady fires, components in nested <Suspense> boundaries might still be loading data.

Logging crashes on the server

By default, all errors on the server are logged to console. You can override this behavior to log crash reports:

If you provide a custom onError implementation, don’t forget to also log errors to the console like above.

Recovering from errors inside the shell

In this example, the shell contains ProfileLayout, ProfileCover, and PostsGlimmer:

If an error occurs while rendering those components, React won’t have any meaningful HTML to send to the client. Override onShellError to send a fallback HTML that doesn’t rely on server rendering as the last resort:

If there is an error while generating the shell, both onError and onShellError will fire. Use onError for error reporting and use onShellError to send the fallback HTML document. Your fallback HTML does not have to be an error page. Instead, you may include an alternative shell that renders your app on the client only.

Recovering from errors outside the shell

In this example, the <Posts /> component is wrapped in <Suspense> so it is not a part of the shell:

If an error happens in the Posts component or somewhere inside it, React will

  1. It will emit the loading fallback for the closest <Suspense> boundary (PostsGlimmer) into the HTML.
  2. It will “give up” on trying to render the Posts content on the server anymore.
  3. When the JavaScript code loads on the client, React will retry rendering Posts on the client.

If retrying rendering Posts on the client also fails, React will throw the error on the client. As with all the errors thrown during rendering, the determines how to present the error to the user. In practice, this means that the user will see a loading indicator until it is certain that the error is not recoverable.

If retrying rendering Posts on the client succeeds, the loading fallback from the server will be replaced with the client rendering output. The user will not know that there was a server error. However, the server onError callback and the client callbacks will fire so that you can get notified about the error.

Setting the status code

introduces a tradeoff. You want to start the page as early as possible so that the user can see the content sooner. However, once you start , you can no longer set the response status code.

By into the shell (above all <Suspense> boundaries) and the rest of the content, you’ve already solved a part of this problem. If the shell errors, you’ll get the onShellError callback which lets you set the error status code. Otherwise, you know that the app may recover on the client, so you can send “OK”.

If a component outside the shell (i.e. inside a <Suspense> boundary) throws an error, React will not stop rendering. This means that the onError callback will fire, but you will still get onShellReady instead of onShellError. This is because React will try to recover from that error on the client,

However, if you’d like, you can use the fact that something has errored to set the status code:

This will only catch errors outside the shell that happened while generating the initial shell content, so it’s not exhaustive. If knowing whether an error occurred for some content is critical, you can move it up into the shell.

Handling different errors in different ways

You can and use the operator to check which error is thrown. For example, you can define a custom NotFoundError and throw it from your component. Then your onError, onShellReady, and onShellError callbacks can do something different depending on the error type:

Keep in mind that once you emit the shell and start , you can’t change the status code.

Waiting for all content to load for crawlers and static generation

offers a better user experience because the user can see the content as it becomes available.

However, when a crawler visits your page, or if you’re generating the pages at the build time, you might want to let all of the content load first and then produce the final HTML output instead of revealing it progressively.

You can wait for all the content to load using the onAllReady callback:

A regular visitor will get a stream of progressively loaded content. A crawler will receive the final HTML output after all the data loads. However, this also means that the crawler will have to wait for all data, some of which might be slow to load or error. Depending on your app, you could choose to send the shell to the crawlers too.

Aborting server rendering

You can force the server rendering to “give up” after a timeout:

React will flush the remaining loading fallbacks as HTML, and will attempt to render the rest on the client.