A information to streaming SSR with React 18

React 18 has launched quite a lot of thrilling adjustments and options. It’s in all probability one thing that you simply’ve heard quite a bit about already, and for good causes. Despite the fact that barely much less eye-catching, there have been additionally some extraordinarily thrilling developments made within the React SSR structure. To know the breakthroughs that React 18 introduced, it’s important to have a look at all the timeline and the incremental steps that led as much as it.

Earlier than we will dive into the before-and-after of SSR, it’s essential to grasp the explanation why we do SSR within the first place. Particularly, we’ll dive into its significance and the elements of it that formed the best way the React staff determined to enhance their SSR structure.

On this article, we’ll be taking a cautious take a look at SSR as a result of it’s necessary to have a basic understanding of this matter and the way it compares in opposition to different strategies, most significantly client-side rendering (CSR). Sadly, we will’t cowl all the factor on this article and can solely concentrate on the necessary elements of SSR within the context of React 18. Though not strictly crucial, we advocate you sweep up on this matter to take advantage of out of this text.

Leap forward:

A brief introduction to SSR

At its core, a very powerful causes for implementing SSR are:

• Efficiency
• SEO (search engine optimization)
• Consumer expertise (UX)

In essence, there exists a selected rendering circulation of a React software utilizing SSR. First, the server takes over the shopper’s duty of fetching all the info and rendering all the React software. After doing so, the ensuing HTML and JavaScript are despatched from the server to the shopper. Lastly, that shopper places the HTML on the display screen and connects it with applicable JavaScript, which is often known as the hydration course of. Now, the shopper receives all the HTML construction as an alternative of 1 huge bundle of JavaScript that it must render itself.

The advantages of this circulation embody simpler entry for net crawlers to index these pages, which improves search engine optimization, and the shopper can shortly present the generated HTML to the consumer as an alternative of a clean display screen, which improves UX. As a result of all of the rendering occurs on the server, the shopper is relieved of this responsibility and doesn’t threat turning into a bottleneck within the state of affairs of low-end gadgets, resulting in improved efficiency.

Nevertheless, the setup as described is simply a place to begin for SSR. Primarily based on how issues are carried out above, there’s much more to realize by way of efficiency and UX. With these two elements in thoughts, let’s make a journey down React SSR reminiscence lane, dive into the problems pre-React 18, expertise its evolution over time, and learn the way React 18 with its streaming options modified the whole lot.

(Streaming) SSR, pre-React 18

Earlier than React 18, Suspense, or any of the brand new streaming options existed, the standard SSR setup in React would look one thing as follows. Whereas totally different implementations will in all probability comprise minor variations, most setups will observe the same structure.

// server/index.ts
import path from 'path';
import fs from 'fs';

import React from 'react';
import ReactDOMServer from 'react-dom/server';
import categorical from 'categorical';

import { App } from '../shopper/App';

const app = categorical();

app.get("https://weblog.logrocket.com/", (req, res) => {
    const appContent = ReactDOMServer.renderToString(<App />);
    const indexFile = path.resolve('./construct/index.html');


    fs.readFile(indexFile, 'utf8', (err, information) => {
        if (err) {
                console.error('One thing went incorrect:', err);
                return res.standing(500).ship('Did not load the app.');
        }

        return res.ship(
                information.substitute('<div id="root"></div>', `<div id="root">${app}</div>`)
        );
    });
});

app.use(categorical.static('./construct'));

app.hear(8080, () => {
    console.log(`Server is listening on port ${PORT}`);
});

// construct/index.html
<!DOCTYPE html>
<html lang="en">
  <head>
    <title>React App</title>
    <script src="https://weblog.logrocket.com/streaming-ssr-with-react-18/most important.js" async defer></script>
  </head>
  <physique>
    <div id="root"></div>
  </physique>
</html>

The largest a part of an SSR setup is the server, so let’s begin with that. On this instance, we’re utilizing Specific to spin up a server to serve the recordsdata from our construct folder on port 8080. When the server receives a request on the root URL, it is going to render the React software to an HTML string utilizing the renderToString perform from the ReactDOMServer package deal.

The outcome then must be despatched again to the shopper. However earlier than that, the server must encompass the rendered software with the suitable HTML construction. To take action, this instance appears within the construct folder for the index.html file, imports it, and injects the rendered software into the foundation factor:

// shopper/index.ts
import React from "react";
import ReactDOM from 'react-dom';
import { App } from './App';

// As a substitute of `ReactDOM.render(...)`
ReactDOM.hydrate(<App />, doc.getElementById('root'));

Then, the principle change that must be made on the shopper aspect is that it doesn’t must render the applying anymore.

As we noticed within the earlier step, the applying is already rendered by the server. So now, the shopper is simply chargeable for hydrating the applying. It does so through the use of the ReactDOM.hydrate perform as an alternative of ReactDOM.render.

Whereas this can be a working setup of React SSR, there are nonetheless a couple of main drawbacks to it relating to efficiency and UX:

• Whereas the server is now chargeable for rendering the React software, the server-side-rendered content material remains to be one massive blob of HTML that must be transmitted in the direction of the shopper earlier than it’s rendered
• Because of the interdependent nature of React parts, the server should anticipate all the info to be fetched earlier than it could actually begin rendering parts, generate the HTML response, and ship it to the shopper
• The shopper nonetheless must load all the app’s JavaScript earlier than it could actually begin hydrating the server’s HTML response
• The hydration course of is one thing that should occur suddenly, however parts are solely interactive after being hydrated, which signifies that customers can’t work together with a web page earlier than hydration is full

In the long run, all of those drawbacks boil all the way down to the present setup, which remains to be a waterfall-like method from the server in the direction of the shopper. This creates an all-or-nothing circulation from one finish to the opposite: both all the HTML response is distributed to the shopper or not, both all the info is finished fetching so the server can begin rendering or not, both all the software is hydrated or not, and both all the web page is responsive or none.

In React 16, the renderToNodeStream server rendering perform was launched on prime of the present renderToString. By way of the setup and outcomes, this didn’t change quite a bit besides that this perform returns a Node.js ReadableStream. This enables the server to stream the HTML to the shopper.

app.get("https://weblog.logrocket.com/", (req, res) => {
    const endHTML = "</div></physique></html>";
    const indexFile = path.resolve('./construct/index.html');

    fs.readFile(indexFile, 'utf8', (err, information) => {
            if (err) {
              console.error('One thing went incorrect:', err);
              return res.standing(500).ship('Did not load the app.');   
        }

        // Break up the HTML the place the React app must be injected and ship the primary half to the shopper
        const beginHTML = information.substitute('</div></physique></html>', '');
        res.write(beginHTML);


        // Render the applying right into a stream utilizing `renderToNodeStream`  and pipe that into the response
        const appStream = ReactDOMServer.renderToNodeStream(<App />);
        appStream.pipe(res, { finish: 'false' });


        // When the server is finished rendering, ship the remainder of the HTML
        appStream.on('finish', () => {
            response.finish(endHTML);
        )};
    });  
});

This new perform partly solves one of many drawbacks we described; specifically, it has to transmit the HTML response as one massive blob from the server to the shopper. Nevertheless, the server nonetheless wants to attend for all the HTML construction to be generated earlier than it could actually begin transmitting something to the shopper. So, it doesn’t actually deal with any of the opposite drawbacks that we described.

Now, let’s take a look at the scenario after React 18 with the newly launched options and the way they deal with these drawbacks.

Streaming SSR post-React 18

The SSR structure post-React 18 includes a handful of various elements. None of those single-handedly fixes any of the drawbacks that we described, however the mixture of them makes the magic work. So, to completely perceive all the setup, it’s essential to look into all of them and what they contribute.

The Suspense part

On the heart of all of it is the well-known Suspense part. It’s the most important gateway in the direction of all of the options that we’ll describe, so let’s begin with it.

// shopper/src/SomeComponent.js
import { lazy, Suspense } from 'react';

const SomeInnerComponent = lazy(() => import('./SomeInnerComponent.js' /* webpackPrefetch: true */));

export default perform SomeComponent() {
    // ...
    return (
        <Suspense fallback={<Spinner />}>
          <SomeInnerComponent />
        </Suspense>
    );
}

Briefly, Suspense is a mechanism for builders to inform React {that a} sure a part of the applying is ready for information. Within the meantime, React will present a fallback UI instead and replace it when the info is prepared.

This doesn’t sound too totally different from earlier approaches, however essentially, it synchronizes React’s rendering course of and the data-fetching course of in a manner that’s extra sleek and built-in. To study extra concerning the particulars, check out this information to Suspense.

Suspense boundaries cut up up the applying into chunks based mostly on their information fetching necessities, which the server can then use to delay rendering what’s pending. In the meantime, it could actually pre-render the chunks for which information is accessible and stream it to the shopper. When the info for a beforehand pending chunk is prepared, the server will then render it and ship it to the shopper once more utilizing the open stream.

Along with React.lazy, which is used to code-split your JavaScript bundle into smaller elements, it offers the primary items of the puzzle in the direction of fixing the remaining waterfall drawbacks.

Nevertheless, the issue was that Suspense and code-splitting utilizing React.lazy weren’t appropriate with SSR but, till React 18.

The renderToPipeableStream API

To know the remaining connecting puzzle items, we’ll check out the Suspense SSR instance that the React groups supplied of their working group dialogue for the structure publish React 18.

import ReactDOMServer from "react-dom/server";
import { App } from "../shopper/App";

app.get("https://weblog.logrocket.com/", (req, res) => {
    res.socket.on('error', (error) => console.log('Deadly', error));

    let didError = false;
    const stream = ReactDOMServer.renderToPipeableStream(
        <App />,
        {
            bootstrapScripts: ['/main.js'],
            onShellReady: () => {
                res.statusCode = didError ? 500 : 200;
                res.setHeader('Content material-type', 'textual content/html');
                stream.pipe(res);
            },
            onError: (error) => {
                didError = true;
                console.log(error);
            } 
        }
    );
});

Probably the most important change in comparison with the earlier setup is the utilization of renderToPipeableStream API on the server aspect. This can be a newly launched server rendering perform in React 18, which returns a pipeable Node.js stream. Whereas the earlier renderToNodeStream couldn’t anticipate information and would buffer all the HTML content material till the top of the stream, the renderToPipeableStream perform doesn’t endure from these limitations.

When the content material above the Suspense boundary is prepared, the onShellReady callback known as. If any error occurred in the intervening time, it’ll be mirrored that within the response in the direction of the shopper. Then, we’ll begin streaming the HTML to the shopper by piping it into the response.

After that, the stream will keep open and transmit any subsequent rendered HTML blocks to the shopper. That is the largest change in comparison with its former model.

This rendering perform absolutely integrates with the Suspense function and code splitting via React.lazy on the aspect of the server, which is what permits the streaming HTML function for SSR. This solves the beforehand described waterfalls of each HTML and information fetching, as the applying might be rendered and transmitted incrementally based mostly on information necessities.

// shopper/index.ts
import React from "react";
import ReactDOMClient from 'react-dom/shopper';
import { App } from './App';

// As a substitute of `ReactDOM.hydrate(...)`
ReactDOMClient.hydrateRoot(doc.getElementById('root'), <App />);

Introducing ReactDOMClient.hydrateRoot for selective hydration

On the shopper aspect, the one change that must be made is how the applying is placed on the display screen. As a alternative for the earlier ReactDOM.hydrate, the React staff has launched a brand new ReactDOMClient.hydrateRoot in React 18. Whereas the change is minimal, it permits quite a lot of enhancements and options. For our context, a very powerful one is selective hydration.

As talked about, Suspense splits the applying into HTML chunks based mostly on information necessities, whereas code-splitting splits the applying into JavaScript chunks. Selective hydration permits React to place these items collectively on the shopper and begin hydrating chunks at totally different timings and priorities. It might begin hydrating as quickly as chunks of HTML and JS are acquired, and prioritize a hydration queue of elements that the consumer interacted with.

This solves the remaining two waterfall points that we had: having to attend for all JavaScript to load earlier than hydrating can begin, and both hydrating all the software or none of it.

The mixture of selective hydration and the opposite talked about options permits React to begin hydrating as quickly as the required JavaScript code is loaded, whereas additionally with the ability to hydrate totally different elements of the applying individually and based mostly on precedence.

What’s subsequent?

React 18 is the cherry on prime of the long-lasting growth of adjustments in its SSR structure over a number of main variations and years of fine-tuning. Suspense and code splitting had been early items of the puzzle, however couldn’t be used to their full potential on the server till the introduction of streaming HTML and selective hydration in React 18.

That can assist you perceive how these adjustments got here to fruition, we appeared on the scenario earlier than and after React 18, explored code examples of typical approaches to setting SSR up, dove into the principle drawbacks that the React SSR structure confronted, and lastly went over how the mix of Suspense, code splitting, streaming HTML, and selective hydration have solved these points.