查看原文
其他

React SSR 实现原理:从 renderToString 到 hydrate

神说要有光zxg 神光的编程秘籍 2023-04-19

SSR 是 Server Side Rendering,服务端渲染,服务端返回渲染出的 html,浏览器解析 html 来构建页面。

其实这是一项很古老的技术,很早之前服务端就是通过 JSP、PHP 等模版引擎,渲染填充数据的模版,产生 html 返回的。只不过这时候没有组件的概念。

有了组件之后再做服务端渲染就不一样了,你需要基于这些组件来填充数据,渲染出 html 返回。

并且在浏览器渲染出 html 后,还要把它关联到对应的组件上,添加交互逻辑和管理之后的渲染。

这时候的 SSR 服务只能是 Node.js 了,因为要服务端也要执行 JS 逻辑,也就是渲染组件。

可以看到,同样的组件在服务端渲染了一次,在客户端渲染了一次,这种可以在双端渲染的方式,叫做同构渲染。

比如这样一个组件:

import { useState } from 'react';

export default function App() {
  return (
    <>
      <h1>Hello, world!</h1>
      <Counter />
    </>

  );
}

function Counter() {
  const [count, setCount] = useState(0);
  return (
    <button onClick={() => setCount(count + 1)}>
      You clicked me {count} times
    </button>

  );
}

在服务端渲染是这样的:

import { renderToString } from 'react-dom/server';
import App from './App';

console.log(renderToString(<App/>));

结果如下:

当然,这里应该有个 http 的 server,把组件 renderToString 的结果拼接成 html 返回。这里省略了。

假设下面就是服务端返回的 SSR 出的 html:

现在浏览器接收到它后,要再次渲染:

import React from 'react';
import { hydrateRoot } from 'react-dom/client';
import './index.css';
import App from './App';

hydrateRoot(document.getElementById('root'), <App/>);

注意,这里执行的不是 renderRoot 的 api,而是 hydrateRoot 的 api。

因为浏览器接收到 html 就会把它渲染出来,这时候已经有标签了,只需要把它和组件关联之后,就可以更新和绑定事件了。

hydrate 会在渲染的过程中,不创建 html 标签,而是直接关联已有的。这样就避免了没必要的渲染。

这就是整个 SSR 的流程:

服务端渲染组件为 string,拼接成 html 返回,浏览器渲染出返回的 html,然后执行 hydrate,把渲染和已有的 html 标签关联。

那服务端是怎么 render 出字符串的,浏览器端又是怎么 hydrate 的呢?

我们分别来看一下:

其实服务端渲染就是拼接 html 的过程,组件和元素分别有不同的渲染逻辑:

组件的话就传入参数执行:

元素的话就拼接字符串:

这样递归渲染一遍,结果就是字符串了:

服务端渲染的部分还是挺简单的,再来看客户端渲染的 hydrate 部分:

这里涉及到 react 的渲染流程,我们简单过一遍:

我们组件里写的这些是 jsx 代码:

它们编译后会变成类似 React.createElement 这种代码,叫做 render function。

render function 执行的结果是 React Element。

类似这样:

我们也经常把 React Element 叫做 vdom。

react 会把 vdom 转成 fiber 的结构,这个过程叫做 reconcile:

在这样的循环里,依次处理 vdom 转 fiber:

根据不同的类型,会做不同的处理:

这个处理分为两个阶段: beginWork 和 completeWork

beginWork 里根据不同的 React Element(vdom)类型,做不同的处理:

常见的几个,比如 FunctionComponent 是函数组件、ClassComponent 是类组件,而 HostComponent 是原生标签、HostText 是原生文本节点,HostRoot 是 fiber 树的根,是 reconcile 的处理入口。

依次处理不同 React Element 转 fiber,这是 beginWork 的部分。

转换完之后就到了 completeWork 的部分:

这个阶段也是按照不同 React Element 类型做的不同处理:

我们主要看 HostComponent 原生标签部分:

在这里做的事情就是创建元素、添加子元素、更新属性、然后把这个元素放到 fiber.stateNode 属性上。

因为 beginWork 的过程是从上往下的,而 completeWork 正好反过来,那就可以按顺序创建元素,组装成一个 dom 树。

小结一下:

我们在组件里写的 jsx 会被编译成 render function,执行产生 vdom(React Element),经过 reconcile 的过程转为 fiber 树。

reconcile 的过程分为 beginWork 和 completeWork 两个阶段,beginWork 从上往下执行不同类型的 React Element 的渲染,而 completeWork 正好反过来,依次创建元素、更新属性,并组装起来。

这里创建的元素是挂载在 fiber.stateNode 上的,并且 dom 元素上也记录着它关联的 fiber 节点:

那如果是 hydrate 呢?还需要创建新元素么?

明显是不用的,hydrate 会在 beginWork 的时候对比当前 dom 是不是可以复用,可以复用的话就直接放到 fiber.stateNode 上了。

首先,beginWork 会从 HostRoot (fiber 的根节点)开始处理:

hydrate 的时候会执行 enterHydrationState 函数:

在这里会开启 isHydrating 标记,并记录当前的 dom 节点,也就是 nextHydratableInstance。

找的顺序是先找到 firstChild,然后依次找 nextSibling,很明显,这是一个深度优先搜索的过程,一层层往下遍历:

所以在我们这个案例里,最先找到的是 h1:

然后 reconcile 的过程中会处理到这个标签,也就是 HostComponent 类型:

这里因为 isHydrating 设置为 true 了,所以会进入 hydrate 逻辑:

这是 nextInstance 就是 h1 标签。

这里是否可以 hydrate 的逻辑很简单:

如果标签名一样就可以 hydrate,也就是直接复用。

把它设置到 fiber.stateNode 上:

然后找下一个可以 hydrate 的 dom 节点,就找到了文本节点:

这样在 beginWork 的过程中依次 hydrate,就把 dom 和对应的 fiber 关联了起来。

然后在 completeWork 的时候,就不用再走创建标签的逻辑,因为 dom 已经有了,就可以跳过这部分。

这就是 hydrate 的原理。

fiber 树创建成功之后,之后的再次渲染就和客户端渲染没有区别了。

这样我们就把 SSR 从 renderToString 到 hydrate 的流程给串联了起来。

总结

SSR 是 JSP、PHP 时代就存在的古老的技术,只不过之前是通过模版引擎,而现在是通过 node 服务渲染组件成字符串,客户端再次渲染,这种叫做同构渲染的模式。

React SSR 是服务端通过 renderToString 把组件树渲染成 html 字符串,浏览器通过 hydrate 把 dom 关联到 fiber 树,加上交互逻辑和再次渲染。

服务端 renderToString 就是递归拼接字符串的过程,遇到组件会传入参数执行,遇到标签会拼接对应的字符串,最终返回一段 html 给浏览器。

浏览器端 hydrate 是在 reconcile 的 beginWork 阶段,依次判断 dom 是否可以复用到当前 fiber,可以的话就设置到 fiber.stateNode,然后在 completeWork 阶段就可以跳过节点的创建。

这就是 React SSR 从服务端的 renderToString 到浏览器端的 hydrate 的全流程的原理。

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存