Analysis and practice of React server-side rendering principle

Most people have heard of the concept of server-side rendering, which we call SSR. Many students may have already done server-side rendering projects in their companies. Mainstream single-page applications, such as Vue or React development projects, generally use the client-side rendering model, which is what we call CSR.

However, this model will bring two obvious problems. The first is that the TTFP time is relatively long. TTFP refers to the first screen display time. At the same time, it does not meet the conditions for SEO ranking, and the ranking on search engines is not very good. So we can use some tools to improve our project and turn the single-page application into a server-side rendering project, so that we can solve these problems.

The current mainstream server-side rendering frameworks, also known as SSR frameworks, are Nuxt.js for Vue and Next.js for React. Here we do not use these SSR frameworks, but build a complete SSR framework from scratch to familiarize ourselves with its underlying principles.

Writing React components on the server

If it is client-side rendering, the browser will first send a request to the browser, the server returns the html file of the page, and then the html sends a request to the server again, the server returns the js file, and the js file is executed in the browser to draw the page structure and render it to the browser to complete the page rendering.

If it is server-side rendering, the process is different. The browser sends a request, the server runs the React code to generate the page, and then the server returns the generated page to the browser, which renders it. In this case the React code is part of the server instead of the frontend.

Here we demonstrate the code. First, you need to initialize the project with npm init, and then install react, express, webpack, webpack-cli, and webpack-node-externals.

We first write a React component. .src/components/Home/index.js, because our js is executed in the node environment, we must follow the CommonJS specification and use require and module.exports for import and export.

const React = require('react');

const Home = () => {
  return <div>home</div>
}

module.exports = {
  default: Home
};

The Home component we developed here cannot be run directly in node. We need to use the webpack tool to package and compile the jsx syntax into js syntax so that nodejs can recognize it. We need to create a webpack.server.js file.

When using webpack on the server side, you need to add a key-value pair with target as node. We know that if the path is used on the server side, it does not need to be packaged into js. If the path is used on the browser side, it needs to be packaged into js. Therefore, the js that needs to be compiled on the server side and on the browser side are completely different. So when we package, we need to tell webpack whether to package the server-side code or the browser-side code.

The entry file is the startup file of our node. Here we write it as ./src/index.js. The output file is named bundle and the directory is in the build folder of the following directory.

const Path = require('path');
const NodeExternals = require('webpack-node-externals'); // Running webpack on the server requires running NodeExternals, which prevents node modules such as express from being packaged into js.

module.exports = {
  target: 'node',
  mode: 'development',
  entry: './src/server/index.js',
  output: {
    filename: 'bundle.js',
    path: Path.resolve(__dirname, 'build')
  },
  externals: [NodeExternals()],
  module: {
    rules:
      {
        test: /.js?$/,
        loader: 'babel-loader',
        exclude: /node_modules/,
        options:
          presets: ['react', 'stage-0', ['env', {
            targets: {
              browsers: ['last 2 versions']
            }
          }]]
        }
      }
    ]
  }
}

Install dependent modules

npm install babel-loader babel-core babel-preset-react babel-preset-stage-0 babel-preset-env --save

Next, we will write a simple service based on the express module. ./src/server/index.js

var express = require('express');
var app = express();
const Home = require('../Components/Home');
app.get('*', function(req, res) {
  res.send(`<h1>hello</h1>`);
})

var server = app.listen(3000);

Run webpack using the webpack.server.js configuration file to execute.

webpack --config webpack.server.js

After packaging, a bundle.js will appear in our directory. This js is the final executable code generated by our packaging. We can use node to run this file and start a server on port 3000. We can access this service by visiting 127.0.0.1:3000 and see the browser output Hello.

node ./build/bundile.js

The above code will be compiled using webpack before running, so it supports the ES Modules specification and no longer forces the use of CommonJS.

src/components/Home/index.js

import React from 'react';

const Home = () => {
  return <div>home</div>
}

export default Home;

We can use the Home component in /src/server/index.js. Here we first need to install react-dom and use renderToString to convert the Home component into a label string. Of course, we need to rely on React here, so we need to introduce React.

import express from 'express';
import Home from '../Components/Home';
import React from 'react';
import { renderToString } from 'react-dom/server';

const app = express();
const content = renderToString(<Home />);
app.get('*', function(req, res) {
  res.send(`
    <html>
      <body>${content}</body>
    </html>
  `);
})

var server = app.listen(3000);

# Repackage webpack --config webpack.server.js
# Run the service node ./build/bundile.js

At this time, the page displays the code of our React component.

React's server-side rendering is based on virtual DOM, and server-side rendering will greatly speed up the first screen rendering of the page. However, server-side rendering also has disadvantages. Client-side rendering React code is executed on the browser side, which consumes the performance of the user's browser side, but server-side rendering consumes the performance of the server side because the React code runs on the server. This greatly consumes the server's performance, because React code consumes a lot of computing performance.

If your project does not need to use SEO optimization and your project access speed is already very fast, it is recommended not to use SSR technology because its cost is still relatively high.

After each modification of our code above, we need to re-execute webpack packaging and start the server, which is too troublesome to debug. In order to solve this problem, we need to do automatic packaging of webpack and restart of node. We add the build command to package.json and use --watch to monitor file changes for automatic packaging.

{
  ...
  "scripts": {
    "build": "webpack --config webpack.server.js --watch"
  }
  ...
}

Just repackaging is not enough, we also need to restart the node server. Here we need to use the nodemon module. Here we use the global installation of nodemon and add a start command in the package.json file to start our node server. Use nodemon to monitor the build file and re-exec "node ./build/bundile.js" after any changes. The double quotes need to be retained here and just translate it.

{
  ...
  "scripts": {
    "start": "nodemon --watch build --exec node \"./build/bundile.js\"",
    "build": "webpack --config webpack.server.js --watch"
  }
  ...
}

At this time we start the server. Here we need to run the following commands in two windows, because no other commands are allowed after building.

npm run build
npm run start

At this time, after we modify the code, the page will be automatically updated.

However, the above process is still a bit troublesome. We need two windows to execute commands. We want one window to execute both commands. We need to use a third-party module npm-run-all, which can be installed globally. Then modify it in package.json.

We should package and debug in the development environment. We create a dev command, execute npm-run-all in it, --parallel means parallel execution, and execute all commands starting with dev:. We add a dev: before start and build. At this time, if I want to start the server and listen for file changes, I can just run npm run dev.

{
  ...
  "scripts": {
    "dev": "npm-run-all --parallel dev:**",
    "dev:start": "nodemon --watch build --exec node \"./build/bundile.js\"",
    "dev:build": "webpack --config webpack.server.js --watch"
  }
  ...
}

What is isomorphism?

For example, in the following code, we bind a click event to div, hoping that a click prompt will pop up when clicking. But after running, we will find that this event is not bound, because the server cannot bind the event.

src/components/Home/index.js

import React from 'react';

const Home = () => {
  return <div onClick={() => { alert('click'); }}>home</div>
}

export default Home;

Generally, we render the page first, and then run the same code on the browser side like a traditional React project, so that the click event will be available.

This leads to the concept of isomorphism. My understanding is that a set of React code is executed once on the server and again on the client.

Isomorphism can solve the problem of invalid click events. First, the server can display the page normally by executing it once, and the client can bind the event by executing it again.

We can load an index.js when the page is rendered, and use app.use to create an access path for static files, so that the index.js accessed will be requested to the /public/index.js file.

app.use(express.static('public'));

app.get('/', function(req, res) {
  res.send(`
    <html>
      <body>
        <div id="root">${content}</div>
        <script src="/index.js"></script>
      </body>
    </html>
  `);
})

public/index.js

console.log('public');

Based on this situation, we can execute the React code once in the browser. We create a new /src/client/index.js here. Paste the code executed by the client. Here we use hydrate instead of render in isomorphic code.

import React from 'react';
import ReactDOM from 'react-dom';

import Home from '../Components/Home';

ReactDOM.hydrate(<Home />, document.getElementById('root'));

Then we also need to create a webpack.client.js file in the root directory. The entry file is ./src/client/index.js, and the export file is public/index.js

const Path = require('path');

module.exports = {
  mode: 'development',
  entry: './src/client/index.js',
  output: {
    filename: 'index.js',
    path: Path.resolve(__dirname, 'public')
  },
  module: {
    rules:
      {
        test: /.js?$/,
        loader: 'babel-loader',
        exclude: /node_modules/,
        options:
          presets: ['react', 'stage-0', ['env', {
            targets: {
              browsers: ['last 2 versions']
            }
          }]]
        }
      }
    ]
  }
}

Add a command to package the client directory in the package.json file

{
  ...
  "scripts": {
    "dev": "npm-run-all --parallel dev:**",
    "dev:start": "nodemon --watch build --exec node \"./build/bundile.js\"",
    "dev:build": "webpack --config webpack.server.js --watch",
    "dev:build": "webpack --config webpack.client.js --watch",
  }
  ...
}

This way we will compile the files that the client runs when we start it. When you visit the page again, you can bind the event.

Next, we organize the code of the above project. There are many duplicates in the webpack.server.js and webpack.client.js files above. We can use the webpack-merge plug-in to merge the contents.

webpack.base.js

module.exports = {
  module: {
    rules:
      {
        test: /.js?$/,
        loader: 'babel-loader',
        exclude: /node_modules/,
        options:
          presets: ['react', 'stage-0', ['env', {
            targets: {
              browsers: ['last 2 versions']
            }
          }]]
        }
      }
    ]
  }
}

webpack.server.js

const Path = require('path');
const NodeExternals = require('webpack-node-externals'); // Running webpack on the server requires running NodeExternals, which prevents node modules such as express from being packaged into js.

const merge = require('webpack-merge');
const config = require('./webpack.base.js');

const serverConfig = {
  target: 'node',
  mode: 'development',
  entry: './src/server/index.js',
  output: {
    filename: 'bundle.js',
    path: Path.resolve(__dirname, 'build')
  },
  externals: [NodeExternals()],
}

module.exports = merge(config, serverConfig);

webpack.client.js

const Path = require('path');
const merge = require('webpack-merge');
const config = require('./webpack.base.js');

const clientConfig = {
  mode: 'development',
  entry: './src/client/index.js',
  output: {
    filename: 'index.js',
    path: Path.resolve(__dirname, 'public')
  }
};

module.exports = merge(config, clientConfig);

The code running on the server is placed in src/server, and the js running on the browser is placed in src/client.

This is the end of this article about the analysis and practice of React server-side rendering. For more relevant React server-side rendering content, please search for previous articles on 123WORDPRESS.COM or continue to browse the following related articles. I hope everyone will support 123WORDPRESS.COM in the future!