renderToReadableStream

renderToReadableStream renders a React tree to aReadable Web Stream.

conststream =awaitrenderToReadableStream(reactNode,options?)

Note

This API depends onWeb Streams. For Node.js, userenderToPipeableStream instead.

Reference

`renderToReadableStream(reactNode, options?)`

CallrenderToReadableStream to render your React tree as HTML into aReadable Web Stream.

import{renderToReadableStream}from'react-dom/server';

asyncfunctionhandler(request){
conststream =awaitrenderToReadableStream(<App/>,{
bootstrapScripts:['/main.js']
});
returnnewResponse(stream,{
headers:{'content-type':'text/html'},
});
}

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

See more examples below.

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 theApp component should render the<html> tag.
optionaloptions: An object with streaming options.
- optionalbootstrapScriptContent: If specified, this string will be placed in an inline<script> tag.
- optionalbootstrapScripts: An array of string URLs for the<script> tags to emit on the page. Use this to include the<script> that callshydrateRoot. Omit it if you don’t want to run React on the client at all.
- optionalbootstrapModules: LikebootstrapScripts, but emits<script type="module"> instead.
- optionalidentifierPrefix: A string prefix React uses for IDs generated byuseId. Useful to avoid conflicts when using multiple roots on the same page. Must be the same prefix as passed tohydrateRoot.
- optionalnamespaceURI: A string with the rootnamespace URI 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.
- optionalnonce: Anonce string to allow scripts forscript-src Content-Security-Policy.
- optionalonError: A callback that fires whenever there is a server error, whetherrecoverable ornot. By default, this only callsconsole.error. If you override it tolog crash reports, make sure that you still callconsole.error. You can also use it toadjust the status code before the shell is emitted.
- optionalprogressiveChunkSize: The number of bytes in a chunk.Read more about the default heuristic.
- optionalsignal: Anabort signal that lets youabort server rendering and render the rest on the client.

Returns

renderToReadableStream returns a Promise:

If rendering theshell is successful, that Promise will resolve to aReadable Web Stream.
If rendering the shell fails, the Promise will be rejected.Use this to output a fallback shell.

The returned stream has an additional property:

allReady: A Promise that resolves when all rendering is complete, including both theshell and all additionalcontent. You canawait stream.allReady before returning a responsefor crawlers and static generation. If you do that, you won’t get any progressive loading. The stream will contain the final HTML.

Usage

Rendering a React tree as HTML to a Readable Web Stream

CallrenderToReadableStream to render your React tree as HTML into aReadable Web Stream:

import{renderToReadableStream}from'react-dom/server';

asyncfunctionhandler(request){
conststream =awaitrenderToReadableStream(<App />,{
bootstrapScripts:['/main.js']
});
returnnewResponse(stream,{
headers:{'content-type':'text/html'},
});
}

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

For example, it might look like this:

exportdefaultfunctionApp(){
return(
<html>
<head>
<metacharSet="utf-8"/>
<metaname="viewport"content="width=device-width, initial-scale=1"/>
<linkrel="stylesheet"href="/styles.css"></link>
<title>My app</title>
</head>
<body>
<Router/>
</body>
</html>
);
}

React will inject thedoctype and yourbootstrap<script> tags into the resulting HTML stream:

<!DOCTYPE html>
<html>
<!-- ... HTML from your components ... -->
</html>
<scriptsrc="/main.js"async=""></script>

On the client, your bootstrap script shouldhydrate the entiredocument with a call tohydrateRoot:

import{hydrateRoot}from'react-dom/client';
importAppfrom'./App.js';

hydrateRoot(document,<App />);

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 ofstyles.css you might end up withstyles.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:

exportdefaultfunctionApp({assetMap}){
return(
<html>
<head>
<title>My app</title>
<linkrel="stylesheet"href={assetMap['styles.css']}></link>
</head>
      ...
</html>
);
}

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

// You'd need to get this JSON from your build tooling, e.g. read it from the build output.
constassetMap ={
'styles.css':'/styles.123456.css',
'main.js':'/main.123456.js'
};

asyncfunctionhandler(request){
conststream =awaitrenderToReadableStream(<AppassetMap={assetMap}/>,{
bootstrapScripts:[assetMap['/main.js']]
});
returnnewResponse(stream,{
headers:{'content-type':'text/html'},
});
}

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

// You'd need to get this JSON from your build tooling.
constassetMap ={
'styles.css':'/styles.123456.css',
'main.js':'/main.123456.js'
};

asyncfunctionhandler(request){
conststream =awaitrenderToReadableStream(<AppassetMap={assetMap}/>,{
// Careful: It's safe to stringify() this because this data isn't user-generated.
bootstrapScriptContent:`window.assetMap =${JSON.stringify(assetMap)};`,
bootstrapScripts:[assetMap['/main.js']],
});
returnnewResponse(stream,{
headers:{'content-type':'text/html'},
});
}

In the example above, thebootstrapScriptContent option adds an extra inline<script> tag that sets the globalwindow.assetMap variable on the client. This lets the client code read the sameassetMap:

import{hydrateRoot}from'react-dom/client';
importAppfrom'./App.js';

hydrateRoot(document,<AppassetMap={window.assetMap}/>);

Both client and server renderApp with the sameassetMap prop, so there are no hydration errors.

Streaming more content as it loads

Streaming 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:

functionProfilePage(){
return(
<ProfileLayout>
<ProfileCover/>
<Sidebar>
<Friends/>
<Photos/>
</Sidebar>
<Posts/>
</ProfileLayout>
);
}

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,wrapPosts in a<Suspense> boundary:

functionProfilePage(){
return(
<ProfileLayout>
<ProfileCover/>
<Sidebar>
<Friends/>
<Photos/>
</Sidebar>
<Suspensefallback={<PostsGlimmer/>}>
<Posts/>
</Suspense>
</ProfileLayout>
);
}

This tells React to start streaming the HTML beforePosts loads its data. React will send the HTML for the loading fallback (PostsGlimmer) first, and then, whenPosts 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 thePostsGlimmer, later replaced by thePosts.

You can furthernest<Suspense> boundaries to create a more granular loading sequence:

functionProfilePage(){
return(
<ProfileLayout>
<ProfileCover/>
<Suspensefallback={<BigSpinner/>}>
<Sidebar>
<Friends/>
<Photos/>
</Sidebar>
<Suspensefallback={<PostsGlimmer/>}>
<Posts/>
</Suspense>
</Suspense>
</ProfileLayout>
);
}

In this example, React can start streaming the page even earlier. OnlyProfileLayout andProfileCover must finish rendering first because they are not wrapped in any<Suspense> boundary. However, ifSidebar,Friends, orPhotos need to load some data, React will send the HTML for theBigSpinner fallback instead. Then, as more data becomes available, more content will continue to be revealed until all of it becomes visible.

Streaming 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.

Note

Only Suspense-enabled data sources will activate the Suspense component. They include:

Data fetching with Suspense-enabled frameworks likeRelay andNext.js
Lazy-loading component code withlazy
Reading the value of a Promise withuse

Suspensedoes not detect when data is fetched inside an Effect or event handler.

The exact way you would load data in thePosts component above depends on your framework. If you use a Suspense-enabled framework, you’ll find the details in its data fetching documentation.

Suspense-enabled data fetching without the use of an opinionated framework is not yet supported. The requirements for implementing a Suspense-enabled data source are unstable and undocumented. An official API for integrating data sources with Suspense will be released in a future version of React.

Specifying what goes into the shell

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

functionProfilePage(){
return(
<ProfileLayout>
<ProfileCover/>
<Suspensefallback={<BigSpinner/>}>
<Sidebar>
<Friends/>
<Photos/>
</Sidebar>
<Suspensefallback={<PostsGlimmer/>}>
<Posts/>
</Suspense>
</Suspense>
</ProfileLayout>
);
}

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

<ProfileLayout>
<ProfileCover/>
<BigSpinner/>
</ProfileLayout>

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 feelsminimal but complete—like a skeleton of the entire page layout.

The async call torenderToReadableStream will resolve to astream as soon as the entire shell has been rendered. Usually, you’ll start streaming then by creating and returning a response with thatstream:

asyncfunctionhandler(request){
conststream =awaitrenderToReadableStream(<App/>,{
bootstrapScripts:['/main.js']
});
returnnewResponse(stream,{
headers:{'content-type':'text/html'},
});
}

By the time thestream is returned, 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:

asyncfunctionhandler(request){
conststream =awaitrenderToReadableStream(<App/>,{
bootstrapScripts:['/main.js'],
onError(error){
console.error(error);
logServerCrashReport(error);
}
});
returnnewResponse(stream,{
headers:{'content-type':'text/html'},
});
}

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

Recovering from errors inside the shell

In this example, the shell containsProfileLayout,ProfileCover, andPostsGlimmer:

functionProfilePage(){
return(
<ProfileLayout>
<ProfileCover/>
<Suspensefallback={<PostsGlimmer/>}>
<Posts/>
</Suspense>
</ProfileLayout>
);
}

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

asyncfunctionhandler(request){
try{
conststream =awaitrenderToReadableStream(<App/>,{
bootstrapScripts:['/main.js'],
onError(error){
console.error(error);
logServerCrashReport(error);
}
});
returnnewResponse(stream,{
headers:{'content-type':'text/html'},
});
}catch(error){
returnnewResponse('<h1>Something went wrong</h1>',{
status:500,
headers:{'content-type':'text/html'},
});
}
}

If there is an error while generating the shell, bothonError and yourcatch block will fire. UseonError for error reporting and use thecatch block 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 isnot a part of the shell:

functionProfilePage(){
return(
<ProfileLayout>
<ProfileCover/>
<Suspensefallback={<PostsGlimmer/>}>
<Posts/>
</Suspense>
</ProfileLayout>
);
}

If an error happens in thePosts component or somewhere inside it, React willtry to recover from it:

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

If retrying renderingPosts on the clientalso fails, React will throw the error on the client. As with all the errors thrown during rendering, theclosest parent error boundary 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 renderingPosts 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 serveronError callback and the clientonRecoverableError callbacks will fire so that you can get notified about the error.

Setting the status code

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

Bydividing your app 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, yourcatch block will run which lets you set the error status code. Otherwise, you know that the app may recover on the client, so you can send “OK”.

asyncfunctionhandler(request){
try{
conststream =awaitrenderToReadableStream(<App/>,{
bootstrapScripts:['/main.js'],
onError(error){
console.error(error);
logServerCrashReport(error);
}
});
returnnewResponse(stream,{
status:200,
headers:{'content-type':'text/html'},
});
}catch(error){
returnnewResponse('<h1>Something went wrong</h1>',{
status:500,
headers:{'content-type':'text/html'},
});
}
}

If a componentoutside the shell (i.e. inside a<Suspense> boundary) throws an error, React will not stop rendering. This means that theonError callback will fire, but your code will continue running without getting into thecatch block. This is because React will try to recover from that error on the client,as described above.

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

asyncfunctionhandler(request){
try{
letdidError =false;
conststream =awaitrenderToReadableStream(<App/>,{
bootstrapScripts:['/main.js'],
onError(error){
didError =true;
console.error(error);
logServerCrashReport(error);
}
});
returnnewResponse(stream,{
status:didError ?500 :200,
headers:{'content-type':'text/html'},
});
}catch(error){
returnnewResponse('<h1>Something went wrong</h1>',{
status:500,
headers:{'content-type':'text/html'},
});
}
}

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 cancreate your ownError subclasses and use theinstanceof operator to check which error is thrown. For example, you can define a customNotFoundError and throw it from your component. Then you can save the error inonError and do something different before returning the response depending on the error type:

asyncfunctionhandler(request){
letdidError =false;
letcaughtError =null;

functiongetStatusCode(){
if(didError){
if(caughtErrorinstanceofNotFoundError){
return404;
}else{
return500;
}
}else{
return200;
}
}

try{
conststream =awaitrenderToReadableStream(<App/>,{
bootstrapScripts:['/main.js'],
onError(error){
didError =true;
caughtError =error;
console.error(error);
logServerCrashReport(error);
}
});
returnnewResponse(stream,{
status:getStatusCode(),
headers:{'content-type':'text/html'},
});
}catch(error){
returnnewResponse('<h1>Something went wrong</h1>',{
status:getStatusCode(),
headers:{'content-type':'text/html'},
});
}
}

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

Waiting for all content to load for crawlers and static generation

Streaming 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 by awaiting thestream.allReady Promise:

asyncfunctionhandler(request){
try{
letdidError =false;
conststream =awaitrenderToReadableStream(<App/>,{
bootstrapScripts:['/main.js'],
onError(error){
didError =true;
console.error(error);
logServerCrashReport(error);
}
});
letisCrawler =// ... depends on your bot detection strategy ...
if(isCrawler){
awaitstream.allReady;
}
returnnewResponse(stream,{
status:didError ?500 :200,
headers:{'content-type':'text/html'},
});
}catch(error){
returnnewResponse('<h1>Something went wrong</h1>',{
status:500,
headers:{'content-type':'text/html'},
});
}
}

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 forall 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:

asyncfunctionhandler(request){
try{
constcontroller =newAbortController();
setTimeout(()=>{
controller.abort();
},10000);

conststream =awaitrenderToReadableStream(<App/>,{
signal:controller.signal,
bootstrapScripts:['/main.js'],
onError(error){
didError =true;
console.error(error);
logServerCrashReport(error);
}
});
// ...

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

PreviousrenderToPipeableStream

NextrenderToStaticMarkup

Movatterモバイル変換

renderToReadableStream

Note

Reference

renderToReadableStream(reactNode, options?)

Parameters

Returns

Usage

Rendering a React tree as HTML to a Readable Web Stream

Deep Dive

Reading CSS and JS asset paths from the build output

Streaming more content as it loads

Note

Specifying what goes into the shell

Logging crashes on the server

Recovering from errors inside the shell

Recovering from errors outside the shell

Setting the status code

Handling different errors in different ways

Waiting for all content to load for crawlers and static generation

Aborting server rendering

`renderToReadableStream(reactNode, options?)`