[JavaScript知识库] 一文带你搞懂 SSR

开发: C++知识库 Java知识库 JavaScript Python PHP知识库人工智能区块链大数据移动开发嵌入式开发工具数据结构与算法开发测试游戏开发网络协议系统运维
教程: HTML教程 CSS教程 JavaScript教程 Go语言教程 JQuery教程 VUE教程 VUE3教程 Bootstrap教程 SQL数据库教程 C语言教程 C++教程 Java教程 Python教程 Python3教程 C#教程
数码: 电脑笔记本显卡显示器固态硬盘硬盘耳机手机 iphone vivo oppo 小米华为单反装机图拉丁

-> JavaScript知识库 -> 一文带你搞懂 SSR -> 正文阅读

[JavaScript知识库]一文带你搞懂 SSR

什么是 SSR

Server-side rendering (SSR)是应用程序通过在服务器上显示网页而不是在浏览器中渲染的能力。服务器端向客户端发送一个完全渲染的页面（准确来说是仅仅是?html?页面）。同时，结合客户端的 JavaScript bundle 使得页面可以运行起来。与 SSR 相对的，还有一种?Client-side rendering（CSR）。CSR 和 SSR 的最大区别只是提供 rendering 的是客户端还是服务端，其本质还有一种东西。故以下如果没有着重提出 CSR 和 SSR 不一样的地方，则默认是一致的。

为什么要 SSR

得益于?react?等前端框架的发展，前后端分离，webpack?等编译工具的流行，以及 ajax 实现页面的局部刷新，使得我们现在的应用程序不再像曾经的应用程序一般需要从服务端获取页面，可以动态的修改局部的页面数据，避免页面频繁跳转影响用户体验等问题。也就是 SPA 越来越成为主流应用程序模型。
但是 SPA 的使用，除了以上提到的优势以外，必然会带来劣势。譬如：

由于需要在页面加载之前就加载所有页面需要的 JavaScript 库，这使得首次打开页面所需要的时间比较久；
需要研发专门针对于 SPA 的 Web 框架（各种具备 SSR 能力的框架，包括 Next.js 等）
搜索引擎爬虫
浏览器历史记录的问题（基于 pushState 的各种 router）

为了解决上述提到的 1. 和 3. 的问题，SSR 开始登上历史的舞台。

SSR 怎么做

基于上述的理论，我们可以设计一个具有 SSR 功能的 React 框架。

首先，我们通过 create-react-app 命令初始化一个 React 项目，可以把初始化完成后的项目理解为具有最简单功能的项目。我们将基于该项目去实现一个 SSR 的功能。

# Yarn
$ yarn create react-app ssr-demo

同学们实践的时候需要注意，当前版本的 cra 命令新建项目的时候，启动会报类似于 Mini.... is not a function的问题。这是因为 mini-css-extract-plugin该插件版本更新导致的，只需要在 package.json里面通过 resolutions 限制mini-css-extract-plugin的版本为 2.4.5 即可

生成项目的目录如下：

./
├── README.md
├── build
├── node_modules
├── package.json
├── public
├── src
└── yarn.lock

已经自动安装完依赖，启动项目我们可以在「本地环境」看到一个最简单的页面。

接下来，我们去实现一个 SSR 功能。首先，我们需要安装 express（如果是 CSR 的话就不需要这一步）

yarn add express

安装完成后，我们需要在 server/index.js文件中编写如下代码

import express from "express";
import serverRenderer from "./serverRenderer.js";

const PORT = 3000;
const path = require("path");

const app = express();
const router = express.Router();

// 当爬虫的请求进来的时候，把所有请求导向 serverRenderer 路由
router.use("*", serverRenderer);

app.use(router);
app.listen(PORT, () => console.log(`listening on: ${PORT}`));

其中serverRenderer该文件内容如下：

import React from "react";
import ReactdomServer from "react-dom/server";

import App from "../src/App";

const path = require("path");
const fs = require("fs");

export default (req, res, next) => {
  // 获取当前项目的 HTML 模板文件路径
  const filePath = path.resolve(__dirname, "..", "build", "index.html");

  // 读取该文件
  fs.readFile(filePath, "utf8", (err, htmlData) => {
    if (err) {
      console.error("err", err);
      return res.status(404).end();
    }

    // 借助 react-dom 依赖下的方法将 JSX 渲染成 HTML string
    const html = ReactDOMServer.renderToString(<App />);

    // 将 HTML string 替换到 root 中
    return res.send(
      htmlData.replace('<div id="root"></div>', `<div id="root">${html}</div>`)
    );
  });
};

如上，我们完成了一个非常简单的具有 SSR 功能的服务端。
但是仅仅如此是不够的，我们还需要在根目录下，新建parser.js将ESM 转成 CommonJS 运行起来，代码如下：

require("ignore-styles");
require("@babel/register")({
  ignore: [/(node_modules)/],
  presets: ["@babel/preset-env", "@babel/preset-react"],
});

require("./server");

解释一下上面引入的包的作用：

@babel/register：该依赖会将 node 后续运行时所需要 require 进来的扩展名为 .es6、.es、.jsx、 .mjs 和 .js 的文件将由 Babel 自动转换。
ignore-styles：该依赖也是一个 Babel 的钩子，主要用于在 Babel 编译的过程中忽略样式文件的导入。

在经过上述的操作之后，我们先 yarn build出我们的产物，然后通过node parser.js来启动 SSR 服务。

经过上述的操作之后，我们设计出了一个非常简单的但合理的 SSR 服务端。作为对比，我们在这里简单的和 Next.js 做对比。

在 Next.js 项目的根目录中的 package.json 中，我们可以看到同样选择了 express 作为服务器.

...
"eslint-plugin-react-hooks": "4.2.0",
"execa": "2.0.3",
"express": "4.17.0",
"faker": "5.5.3",
...

我们可以在 ~/packages/next/server/next.ts文件夹中，发现 Next.js会通过 createServer方法，启动一个 NextServer 对象，该对象负责启动服务器以及渲染模板模板。
命令调用如下：

在 [Next.js](https://nextjs.org/docs/basic-features/pages#server-side-rendering)的官网中，我们可以看到其支持在页面通过 getServerSideProps函数，来实现动态获取接口数据。其实，在大多数支持 SSR 的框架库中，都有类似的设计。因为 SPA 的应用，难免需要通过服务端获取动态数据，并渲染页面，而实现渲染动态数据的 SSR 的设计思路都较为一致。即在该页面的组件同一文件中导出一固定方法，并且 return 某一固定格式。框架会将该数据用作初始数据对页面进行 SSR 渲染。

我们以Next.js为例，了解了 SSR 的大致设计思路，那么接下来我们了解一下 CSR 的大致思路.。

CSR 可以理解为阉割版的 SSR，只实现了 SSR 的预渲染功能。一般用于静态网站，不具备动态获取数据的功能。

CSR 的渲染思路同 SSR 一致，不同点在于 SSR 是需要安装 express而 CSR 不需要安装 express。这也就导致了 CSR 和 SSR 在部署流程上的不同。SSR 项目如 Next.js应用在执行完 build 命令后，可以通过 start 命令执行启动服务器，不再需要配合 nginx 的反向代理。而 CSR 项目如 Umi仍然需要 nginx 的代理。

CSR 最大的不同点在于编译后产物的不同。通常一个前端项目在编译后的产物包括一下：