React Streaming SSR原理示例深入解析

2024-10-11 16:50:15

功能简介

React 18 提供了一种新的 SSR 渲染模式： Streaming SSR。通过 Streaming SSR，我们可以实现以下两个功能：

Streaming HTML：服务端可以分段传输 HTML 到浏览器，而不是像 React 18 以前一样，需要等待服务端渲染完成整个页面后才返回给浏览器。这样，浏览器可以更快的启动 HTML 的渲染，提高 FP、FCP 等性能指标。
Selective Hydration：在浏览器端 hydration 阶段，可以只对已经完成渲染的区域做 hydration，而不需要等待整个页面渲染完成、所有组件的 JS bundle 加载完成，才能开始 hydration。这样可以更早的对已经完成渲染的区域做事件绑定，从而让页面获得更好的可交互性。

基本原理

使用示例

React 官网给出的一个简单的使用示例（以 Node.js 环境下的 API 为例）如下：

let didError = false;
const stream = renderToPipeableStream(
  <App />,
  {
    bootstrapScripts: ["main.js"],
    onShellReady() {
      // The content above all Suspense boundaries is ready.
      // If something errored before we started streaming,
      // we set the error code appropriately.
      res.statusCode = didError ? 500 : 200;
      res.setHeader('Content-type', 'text/html');
      stream.pipe(res);
    },
    onShellError(error) {
      // Something errored before we could complete the shell
      // so we emit an alternative shell.
      res.statusCode = 500;
      res.send('<!doctype html><p>Loading...</p><script src="clientrender.js"></script>');
    },
    onAllReady() {
      // stream.pipe(res);
    },
    onError(err) {
      didError = true;
      console.error(err);
    }
  }
);

renderToPipeableStream 是在 Node.js 环境下实现 Streaming SSR 的 API。

Streaming HTML

HTTP 支持以 stream 格式进行数据传输。当 HTTP 的 Response header 设置 Transfer-Encoding: chunked 时，服务器端就可以将 Response 分段返回。一个简单示例：

const http = require("http");
const url = require("url");
const sleep = (ms) => {
  return new Promise((resolve) => {
    setTimeout(resolve, ms);
  });
};
const server = http.createServer(async (req, res) => {
  const { pathname } = url.parse(req.url);
  if (pathname === "/") {
    res.statusCode = 200;
    res.setHeader("Content-Type", "text/html");
    res.setHeader("Transfer-Encoding", "chunked");
    res.write("<html><body><div>First segment</div>");
    // 手动设置延时，让分段显示的效果更加明显
    await sleep(2000);
    res.write("<div>Second segment</div></body></html>");
    res.end();
    return;
  }
  res.writeHead(200, { "Content-Type": "text/plain" });
  res.end("okay");
});
server.listen(8080);

当访问 localhost:8080 时，「First segment」和「Second segment」会分 2 次传输到浏览器端，「First segment」先显示到页面上，2s 延迟后，「Second segment」再显示到页面上。

React 中的 Streaming HTML 要更加复杂。例如，对下面的 App 组件做 SSR：

//文件1： Content.js
export default function Content() {
  return (
    <div> This is content </div>
  );
}
// 文件2：App.js
import { Suspense, lazy } from "react";
const Content = lazy(() => import("./Content"));
export default function App() {
  return (
    <html>
      <head></head>
      <body>
        <div>App shell</div>
        <Suspense>
          <Content />
        </Suspense>
      </body>
    </html>
  );
}

第 1 次访问页面时，SSR 渲染的结果会分成 2 段传输，传输的第 1 段数据，经过格式化后，如下：

<!DOCTYPE html>
<html>
   <head></head>
   <body>
      <div>App shell</div>
      <!--$?-->
      <template id="B:0"></template>
      <!--/$-->
   </body>
</html>

其中 template 标签的用途是为后续传输的 Suspense 的 children 渲染结果占位，注释和中间的内容，表示是异步渲染出来的。

传输的第 2 段数据，经过格式化后，如下：

<div hidden id="S:0">
  <div> This is content </div>
</div>
<script>
  function $RC(a, b) {
    a = document.getElementById(a);
    b = document.getElementById(b);
    b.parentNode.removeChild(b);
    if (a) {
        a = a.previousSibling;
        var f = a.parentNode,
            c = a.nextSibling,
            e = 0;
        do {
            if (c && 8 === c.nodeType) {
                var d = c.data;
                if ("/$" === d)
                    if (0 === e) break;
                    else e--;
                else "$" !== d && "$?" !== d && "$!" !== d || e++
            }
            d = c.nextSibling;
            f.removeChild(c);
            c = d
        } while (c);
        for (; b.firstChild;) f.insertBefore(b.firstChild, c);
        a.data = "$";
        a._reactRetry && a._reactRetry()
    }
  };
  $RC("B:0", "S:0")
</script>

id="S:0" 的 div 正是 Suspense 的 children 的渲染结果，但是这个 div 设置了 hidden 属性。接下来的 $RC 函数，会负责将这个 div 插入到第 1 段数据中 template 标签所在的位置，同时删除 template 标签。

总结一下

React Streaming SSR ，会先传输所有以上层级的可以同步渲染得到的 html 结构，当内的组件渲染完成后，会把这部分组件对应的渲染结果，连同一个 JS 函数再传输到浏览器端，这个 JS 函数会更新 dom ，得到最终的完整 HTML 结构。

当第 2 次访问页面时，html 结构会一次性返回，而不会分成 2 次传输。这时候组件为什么没有将传输的数据分段呢？这是因为第 1 次请求时， Content 组件对应的 JS 模块在服务器端已经被加载到模块缓存中，再次请求时，加载 Content组件是一个同步过程，所以整个渲染过程是同步的，不存在分段传输渲染结果的情况。由此可见，只有当的 children，需要被异步渲染时，SSR 返回的 HTML 才会被分段传输。

除了动态加载 JS 模块（code splitting）会产生分段传输数据的效果外，组件内获取异步数据则是更加常见的适用 Streaming SSR 的场景。

我们将 Content 组件做改造，通过调用异步函数 getData 获取数据：

let data;
const getData = () => {
  if (!data) {
    data = new Promise((resolve) => {
      // 延迟 2s 返回数据
      setTimeout(() => {
        data = "content from remote";
        resolve();
      }, 2000);
    });
    throw data;
  }
  // promise-like
  if (data && data.then) {
    throw data;
  }
  const result = data;
  data = undefined;
  return result;
};
export default function Content() {
  // 获取异步数据
  const data = getData();
  return <div>{data}</div>;
}

这样，Content 的内容会延迟 2s，待获取到 data 数据后传输到浏览器显示。示例代码（codesandbox 最近升级了，在 html 的 head 里注入了会阻塞 DOM 渲染的 JS，导致 Streaming SSR 效果可能失效，可以把代码复制到本地测试）。

注意：在数据未准备好前，getData 必须 throw 一个 promise，promise 会被 Suspense 组件捕获，这样才能保证 Streaming SSR 的顺利执行。

Selective Hydration

React 18 之前，SSR 实际上是不支持 code splitting 的，只能使用一些 workaround，常见的方式有：1. 对于需要 code splitting 的组件，不在服务端渲染，而是在浏览器端渲染；2. 提前将 code splitting 的 JS 写到 html script 标签中，在客户端等待所有的 JS 加载完成后再执行 hydration。

这一点 React Team 的 Dan 在 Suspense 的 RFC 中也有提及：

To the best of our knowledge, even popular workarounds forced you to choose between either opting out of SSR for code-split components or hydrating them after all their code loads, somewhat defeating the purpose of code splitting.

当前 Modern.js 对于这种情况的处理，采用的是第 2 种方式。Modern.js 利用 @loadable/component 在 SSR 阶段，收集做了 code splitting 的组件的 JS bundle，然后把这些 JS bundle 添加到 html script 标签中，@loadable/component 提供了一个 API loadableReady ，在等待 JS bundle 加载完成后，才执行 hydration 。示意代码如下：

loadableReady(function(){
  hydrateRoot(root, <App/>)
})

如果在没有等待所有的 JS bundle 都加载完成，就开始 hydration，会出现什么问题呢？

考虑下面的例子，Content 组件做了 code splitting，如果在浏览端，在 Content 组件的 JS bundle 还未加载完成时，就开始 hydration，hydration 得到的 HTML 结构将缺少 Content 组件的内容，而服务端 SSR 返回的结构则是包含 Content 组件的，导致如下报错：

Hydration failed because the initial UI does not match what was rendered on the server.

import loadable from '@loadable/component'
const Content = loadable(() => import("./Content"));
export default function App() {
  return (
    <html>
      <head></head>
      <body>
        <div>App shell</div>
        <Content />
      </body>
    </html>
  );
}

把上面的代码，用 React 18 的 lazy 和 Suspense 改写，就可以支持 Selective Hydration，使得 SSR 真正支持 code splitting：

import {lazy, Suspense} from 'react'
const Content = lazy(() => import("./Content"));
export default function App() {
  return (
    <html>
      <head></head>
      <body>
        <div>App shell</div>
        <Suspense>
          <Content />
        </Suspense>
      </body>
    </html>
  );
}

如果 Content 组件的 JS bundle 还没有加载完成，在 hydration 阶段，渲染到 Suspense 节点时会跳出，而不会让整个 hydration 过程失败。

Selective Hydration 还有另外一种使用场景：同步导入 Content 组件（不做 code splitting），但是需要注意 Content 组件内仍然有异步的读取数据操作（见上文代码），另外增加一个 SideBar 组件，用于验证事件绑定，代码如下：

import {lazy, Suspense, useState} from 'react'
// 同步导入 Content 组件
import Content from './Content';
const Sidebar = () => {
  const [color, setColor] = useState('black');
  return (
    <div className="home">
      <div style={{ color }}>Siderbar</div>
      <button
        onClick={() => {
          setColor(color === 'black' ? 'red' : 'black');
        }}
      >
        change
      </button>
    </div>
  );
};
export default function App() {
  return (
    <html>
      <head></head>
      <body>
        <div>App shell</div>
        <Sidebar />
        <Suspense>
          <Content />
        </Suspense>
      </body>
    </html>
  );
}

访问页面时，在渲染出 Content 组件前，Siderbar 就已经可以交互了（点击 change 按钮，文字颜色会改变）。说明，虽然所有组件使用一个 JS bundle 做 hydration，但是如果 Suspense 内的组件没有完成渲染，并不会影响其他已经渲染出的组件做 hydration。示例代码。

总结一 下，React 18 的 hydration 阶段，当渲染到 Suspense 组件时，会根据 Suspense 的 children 是否已经渲染完成，而选择是否继续向子组件执行 hydration。未渲染完成的组件待渲染完成后，会恢复执行 hydration。 Suspense 的 children 异步渲染的两种场景：1. children 组件做了 code splitting；2. children 组件中有异步操作。

降级逻辑

Streaming SSR 过程中，如果某个 Suspense 的 children 渲染过程抛出异常，那么这个 children 组件将降级到 CSR，即在浏览器端重新尝试渲染。

例如，我们对前面使用的 Content 组件做改造，刻意在服务端 SSR 阶段抛出异常：

export default function Content() {
  const _data = getData();
  // 制造异常
  if(typeof window === 'undefined'){
    data = undefined
    throw Error('SSR Error')
  }
  return (
    <div>
      {_data}
    </div>
  );
}

访问页面时，Response 返回的第二段数据，格式化后如下所示：

<script>
  function $RX(b, c, d, e) {
    var a = document.getElementById(b);
    b = a.previousSibling;
    b.data = "$!";
    a = a.dataset;
    c && (a.dgst = c);
    d && (a.msg = d);
    e && (a.stck = e);
    b._reactRetry && b._reactRetry()
  };
  $RX("B:0", "", "SSR Error", "\n    at Content\n    at Lazy\n    at Content\n    at Lazy\n    at Suspense\n    at body\n    at html\n    at App\n    at DataProvider (/Users/bytedance/work/examples/stream-ssr-demo/src/data.js:18:23)")
 </script>

第二段数据中返回了 RX 函数，而不是渲染正确情况下的 RX 函数，而不是渲染正确情况下的 RX 函数，而不是渲染正确情况下的 RC 函数。RX 会将渲染出错的Suspense在HTML中对应的Comment标签 <!−−RX 会将渲染出错的 Suspense 在 HTML 中对应的 Comment 标签  修改为，表示这个 Suspense 的 children 需要在浏览器端执行降级渲染。当执行 $RX 时，如果父组件已经完成 hydration，会调用 Comment 节点上的 _reactRetry 方法，立即执行对需要降级的组件的渲染；否则等待父组件执行时 hydration，再“顺道”执行渲染。

当 Suspense 的 children SSR 阶段渲染失败时，可以在 renderToPipeableStream 的 onError 回调中执行专门的逻辑处理，例如下面的例子中，会打印出错误日志，并将响应的状态码设置为 500。

如果还没有渲染到任一 Suspense 组件时，就发生了错误，这意味着应用对应的整棵组件树都没有渲染成功，SSR 完全失败，这个时候 onShellReady 不会被调用，onShellError 会调用，我们可以在 onShellError 中返回 CSR 使用的 HTML 模版，让整个应用完全降级到 CSR 。

 let didError = false;
 const stream = renderToPipeableStream(
    <App assets={assets} />,
    {
      onShellReady() {
        // If something errored before we started streaming, we set the error code appropriately.
        res.statusCode = didError ? 500 : 200;
        res.setHeader("Content-type", "text/html");
        stream.pipe(res);
      },
      onError(x) {
        didError = true;
        console.error(x);
      },
      onShellError(x) {
        didError = true;
        res.send(<html>...</html>)//返回 CSR 使用的 HTML 模版，整棵组件树降级到 CSR
      }
    }
  );

JS 和 CSS 设置

当前，我们还没有介绍如何在 Streaming SSR 中设置 JS 和 CSS 文件。有三种方式：

在 HTML 组件中设置示例如下：

function Html({ assets, children, title }) {
    return (
      <html>
        <head>
          <title>{title}</title>
          <link rel="stylesheet" href={assets["main.css"]} />
          <script src={assets["main.js"]}></script>
        </head>
        <body>
          <noscript
            dangerouslySetInnerHTML={{
              __html: `<b>Enable JavaScript to run this app.</b>`
            }}
          />
          {children}
          <script
            dangerouslySetInnerHTML={{
              __html: `assetManifest = ${JSON.stringify(assets)};`
            }}
          />
        </body>
      </html>
    );
  }
function App({assets}) {
   return (
     <Html assets={assets} title="Hello">
        {/* other components */}
     </Html>
   );
 }
  hydrateRoot(document, <App assets={window.assetManifest} />);

我们将 html、head、body 等这些标签也通过 React 组件表示，这样对 JS 和 CSS 的设置，也可以在 JSX 中完成。示例中，通过 assets 属性，设置 HTML 组件需要引人的 JS 和 CSS 文件。 SSR 阶段时，assets 一般是通过读取 webpack 等构建工具的构建产物结果得到的，assets 还会写入到一个 script 的assetManifest 变量上，这样在 hydration 阶段，App 组件可以通过 window.assetManifest 获取到 assets 信息。

在返回第一段数据时添加这种方式下，html、head、body 等这些最外层标签，通过 HTML 模版注入到 Streaming SSR 返回的第一段数据中。示例如下：

import { Transform } from 'stream';
// 代表传输的第一段数据
let isShellStream = true;
const injectTemplateTransform = new Transform({
  transform(chunk, _encoding, callback) {
    if (isShellStream) {
      // headTpl 代表 <html><head>...</head><body><div id='root'> 部分的模版
      // tailTpl 代表 </div></body></html> 部分的模版
      this.push(`${headTpl}${chunk.toString()}${tailTpl}`));
      isShellStream = false;
    } else {
      this.push(chunk);
    }
    callback();
  },
});
const stream = renderToPipeableStream(
  <App />,
  {
    onShellReady() {
      res.setHeader('Content-type', 'text/html');
      stream.pipe(injectTemplateTransform).pipe(res);
    },
  }
);

在构建阶段，将 HTML 所需的 JS 和 CSS 文件，构建到 html 模版中。然后通过创建一个 Transform 流，在传输第一段数据时，将 headTpl 、tailTpl 的 html 模版数据添加到第一段数据的两端。

通过参数 bootstrapScripts 设置通过 renderToPipeableStream 的第二个参数，设置 bootstrapScripts 的值，``bootstrapScripts` 的值为 HTML 所需的 JS 文件路径。注意，这种方式不支持设置 CSS 文件。示例如下：

const stream = renderToPipeableStream(
  <App />,
  {
    bootstrapScripts: ["main.js"],
    onShellReady() {
      res.setHeader('Content-type', 'text/html');
      stream.pipe(res);
    },
  }
);

源码解析

数据结构

Streaming SSR 的实现，主要涉及 Segment、Boundary、Task 和 Request 4种数据结构。

Segment

代表 Streaming SSR 分段传输过程中的每段数据。

简化后的 Segment 类型及字段说明如下：

type Segment = {
  // segment 状态。依次代表 pending、completed、flushed、aborted、errored
  status: 0 | 1 | 2 | 3 | 4,
  // 真正要传输到浏览器端的数据
  chunks: Array<string | Uint8Array>,
  // 子级 Segment，当遇到 Suspense Boundary 时会创建新的 Segment，
  // 作为当前 Segment 的子级 Segment
  children: Array<Segment>,
  // 在父级 Segment 的 chunks 中的位置索引，如果没有父级 Segment, 则为 0
  index: number,
  // 如果这个 Segment 代表 Suspense 组件的 fallback，
  // boundary 代表 Suspense 组件内部真正内容对应的 Boundary
  boundary: null | SuspenseBoundary,
};

status

新建时，状态为 pending；当 Segment 已经获取到需要传输的数据时，状态为 completed；当 Segment 的数据已经写入到 HTTP Response 对象时，状态为 flushed。

children

当 React 解析到 Suspense 组件时，会创建新的 Segment，存储到当前 Segment 的 children 中。例如以下 App 组件：

import { lazy } from 'react'
const Content = lazy(() => import('./Content' ));
function App = (props) => {
  return (
    <div>
      <div>App</div>
      <Suspense fallback={<Spinner />}>
         <Content />
      </Suspense>
    </div>
  )
}

React 会创建 3 个 Segment：

Segment 1 对应的 DOM 结构为：

<div>
  <div>App<div/>
</div>

Segement 1 对应所有 Suspense 组件之上的内容，可以称为 Root Segment

Segment 2 对应 Spinner 组件渲染出的内容。同时 Segment 2 会存储到 Segment 1 的 children 属性中。

Segment 3 对应 Suspense 组件的 children 渲染出的内容。注意，因为被 Suspense 组件分割，Segment 3 的内容和 Segment 1 、Segment 2 的内容，在 HTTP 传输过程中，是分成 2 段传输的（也有可能是在 1 段中传输，后面会介绍），所以 Segment 3 并不会保存到 Segment 1 的 children中。

index

继续考虑上面的例子，Segment 1 chunks 保存的数组元素，我们做一下简化，用以下 3 个元素示意：

[0]: <div>
[1]: <div>App</div>
[2]: </div>

Segment 2 chunks 中的数据，需要插入到 Segment 1 chunks 数组中的第 1 个元素之后的位置，才能保证传输的 dom 结构顺序是正确的，所以这个例子中 index 等于 2 。

Boundary

SSR 逻辑分段的“分界线”，每个 Suspense 组件对应 1 个 Suspense Boundary。

例如以下 App 组件有 2 个 Suspense 组件，会创建 2 个 Boundary，这 2 个 Boundary 实际上将整个组件的解析过程分成了 3 部分，Boundary 1 以上的部分，我们也可以视做一个 Boundary，称为 Root Boundary。

import { lazy } from 'react'
const Content = lazy(() => import('./Content' ));
const Comments = lazy(() => import('./Comments' ));
function App = (props) => {
  return (
    <div>
      <div>App<div/>
      {/* Boundary 1 */}
      <Suspense fallback={<Spinner />}>
         <Content />
         {/* Boundary 2 */}
         <Suspense fallback={<Spinner />}>
           <Comments />
         </Suspense>
      </Suspense>
    </div>
  )
}

简化后的 Boundary （ React 代码中命名为 SuspenseBoundary）类型及字段说明如下：

type SuspenseBoundary = {
  // 当前 boundary 范围内的 pending 状态的 task 数量
  pendingTasks: number,
  // 当前 boundary 范围内的已完成渲染的 Segment
  completedSegments: Array<Segment>,
};

Task

1 个 Task 代表一个将组件树渲染成 DOM 结构的任务。一般情况下，一个应用对应一棵组件树，似乎一个应用只需要 1 个 Task 即可。但是，因为 Suspense 将组件树分成了多个子组件树，子组件树可以是异步处理的，所以实际上会需要多个 Task。

简化后的 Task 类型及字段说明如下：

type Task = {
  // Task 对应的组件树
  node: ReactNodeList,
  // Task 对应的 Boundary
  blockedBoundary: null | SuspenseBoundary,
  // Task 对应的 Segment
  blockedSegment: Segment,
  // 后面介绍
  ping: () => void,
}

blockedBoundary 的值可以为 null 或 SuspenseBoundary。 null 表示 task 代表所有 Suspense 组件之上的组件树的渲染任务，即 root task；

SuspenseBoundary 表示 task 代表某个 Suspense 组件内的组件树的异步渲染任务。

通过如下示例进一步说明：

import { lazy } from 'react'
const Content = lazy(() => import('./Content' ));
function App = (props) => {
  return (
    <div>
      <div>App</div>
      <Suspense fallback={<Spinner />}>
         <Content />
      </Suspense>
    </div>
  )
}

在 SSR 渲染开始时，会创建一个 Task，代表 App 作为根节点的组件树的渲染任务。这个 Task 的 Boundary 为 Root Boundary，所以为 null。

如果是第一次请求，因为 Content 组件做了 code splitting，所以 Content 组件代码的加载是异步的。这时会再创建 2 个 Task，一个为代表包裹 Content 组件的 React.lazy 为根节点的组件树的渲染任务；另一个为代表 Spinner 作为根节点的组件树的渲染任务。

这种情况，SSR 渲染结果会分成 2 次传输。

如果不是第一次请求，这是 Content 模块已经被加载到缓存中，再次加载不存在异步问题。此时，整个组件树的渲染是一个同步过程，也不需要使用 fallback 组件 Spinner ，所以只需要一个 Task 即可，即 App 作为根节点的 Task。

这种情况，SSR 渲染结果只需要 1 次传输。

Request

Request 是 SSR 逻辑中的最顶层对象。每 1 个 SSR 请求，会生成一个 Request 对象，存储这次 SSR 过程所需要的 Task、Boundary、Segement 等相关信息，以及 SSR 过程中不同时机的回调函数（onShellReady ，onAllReady ，onShellError，onError ）。

简化后的 Request 类型及字段说明如下：

type Request = {
  // 请求结果的输出流，即 Response 对象
  destination: null | Destination,
  // 所有未完成的 Task 数量，当等于 0 时，表示本次 SSR 完成，可以关闭 HTTP 连接
  allPendingTasks: number,
  // Root Boundary 范围内的未完成的 Task 数量，当等于 0 时，Root Boundary 渲染完成
  pendingRootTasks: number,
  // 等待执行的 Task
  pingedTasks: Array<Task>,
  // 已完成的 Root Segment
  completedRootSegment: null | Segment,
  // 已完成的 Boundary
  completedBoundaries: Array<SuspenseBoundary>,
  // Root Boundary 渲染完成后的回调
  onShellReady: () => void,
  // Root Boundary 渲染过程中，出错的回调
  onShellError: (error: mixed) => void,
  // 所有 Boundary 都渲染完成，即 SSR 完成的回调
  onAllReady: () => void,
  // Root Boundary 渲染完成后，在后续 Suspense Boundary 渲染过程中出错的回调
  onError: (error: mixed) => ?string,
};

主要流程

renderToPipeableStream 涉及的关键函数调用过程如下图所示：

renderToPipeableStream 的关键代码如下：

function renderToPipeableStream(
  children: ReactNodeList,
  options?: Options,
): PipeableStream {
  // 创建请求对象 Request
  const request = createRequest(children, options);
  // 启动组件树的渲染任务
  startWork(request);
  return {
    pipe<T: Writable>(destination: T): T {
      // 开始将渲染结果写入输出流
      startFlowing(request, destination);
      return destination;
    },
    abort(reason: mixed) {
      abort(request, reason);
    },
  };
}

为了便于理解主干流程，本节列出的 React 源码，做了大量删减和微调，并非完整源码。

完整源码请参考：ReactDOMFizzServerNode.js 、ReactFizzServer.js、 ReactServerStreamConfigNode.js 等文件。

分析上面的代码调用过程，我们把 SSR 过程分为三个阶段：

创建请求对象创建请求对象即创建 Request 数据结构，对应 createRequest ，主要逻辑为：a. 根据入参 options ，创建 request 对象，设置 onShellReady 、onAllReady 等回调函数b. 创建 root segment，关联的 boundary 为 root boundary，即 nullc. 根据入参 children 和 root segment，创建 root taskd. 将 root task 保存到 request 的 pingedTasks 中，root task 将作为后续渲染操作的起点

export function createRequest(
  children: ReactNodeList,
  options?: Options,
): Request {
  const pingedTasks = [];
  const request = {
    //  初始化 request
  };
  // This segment represents the root fallback.
  const rootSegment = {
    status: PENDING,
    index: 0,
    chunks: [],
    children: [],
  };
  const rootTask = createTask(
    request,
    children,
    null,
    rootSegment
  );
  pingedTasks.push(rootTask);
  return request;
}

Root task 由createTask 创建，创建 task 时，需要设置 task 关联的待渲染的组件树（ node ）、 Boundary( blockedBoundary ) 和 Segement ( blockedSegment )，同时还需要修改 request和 blockedBoundary 关联的待完成的 task 数量。

createTask 简化后的代码及注释如下：

function createTask(
  request: Request,
  node: ReactNodeList,
  blockedBoundary: Root | SuspenseBoundary,
  blockedSegment: Segment,
): Task {
  // allPendingTasks 自增 1
  request.allPendingTasks++;
  // 如果是 root boundary, pendingRootTasks 自增1；
  // 否则把对应 boundary 范围里的 pendingTask 自增1
  if (blockedBoundary === null) {
    request.pendingRootTasks++;
  } else {
    blockedBoundary.pendingTasks++;
  }
  // 创建 task，ping 的作用后续介绍
  const task: Task = ({
    node,
    ping: () => pingTask(request, task),
    blockedBoundary,
    blockedSegment,
  }: any);
  return task;
}

2、启动渲染流程创建好 root task 后，就可以以 root task 作为起点，启动组件的渲染流程了，对应 startWork 。

主要逻辑可以从 startWork 内部调用performWork 开始看：

export function performWork(request: Request): void {
  const pingedTasks = request.pingedTasks;
  let i;
  for (i = 0; i < pingedTasks.length; i++) {
    const task = pingedTasks[i];
    retryTask(request, task);
  }
  pingedTasks.splice(0, i);
  if (request.destination !== null) {
    flushCompletedQueues(request, request.destination);
  }
}

performWork遍历 request 的pingedTasks，对每一个 task 执行 retryTask 。retryTask 主要逻辑如下：

通过调用 renderNodeDestructive ，对 task 包含的 React node 节点执行渲染逻辑。
如果renderNodeDestructive 执行过程中没有抛出异常：a. 表示 task 关联的渲染任务完成，将 task 关联的 segment 状态设置为完成状态。b. 调用 finishedTask ，对 request 上的 segment 信息做更新：如果是 root boundary 的task，将当前 task 关联的 segment 赋值给 request 的completedRootSegment ；如果是 suspense boundary，将当前 task 关联的 segment 添加到关联 boundary 的 completedSegments。注意，onShellReady 回调也是在这个函数中执行的，当 root boundary 上的 task 都已经执行完成（request.pendingRootTasks === 0），就会调用onShellReady 。
如果renderNodeDestructive 执行过程中抛出异常（主要针对 throw promise 场景）：a. 捕获异常，如果是 promise-like 对象，在 promise resolve 后，把当前 task 重新放到 request 的 pingedTask 中，等待重新执行（调用 performWork ）。

retryTask 主要代码如下：

function retryTask(request: Request, task: Task): void {
  const segment = task.blockedSegment;
  try {
    renderNodeDestructive(request, task, task.node);
    segment.status = COMPLETED;
    finishedTask(request, task.blockedBoundary, segment);
  } catch (x) {
    resetHooksState();
    if (typeof x === 'object' && x !== null && typeof x.then === 'function') {
      // Something suspended again, let's pick it back up later.
      const ping = task.ping;
      x.then(ping, ping);
    }
  }
}

3.a 步骤中，需要依赖 12行的 task.ping 把 task 重新放回 request 的pingedTasks。

task.ping 对应函数：() => pingTask(request, task)，pingTask 实现如下：

function pingTask(request: Request, task: Task): void {
  const pingedTasks = request.pingedTasks;
  pingedTasks.push(task);
  scheduleWork(() => performWork(request));
}

renderNodeDestructive 对 task 的 node 属性代表的组件树，做 深度优先 遍历，一边将组件渲染为 dom 节点，一边将 dom 节点的信息存储到 task 的 blockedSegment 属性中。

Streaming SSR 实现的一个关键，是对Suspense组件的渲染逻辑。当 renderNodeDestructive 遍历到 Suspense 组件时，会调用renderSuspenseBoundary 执行渲染逻辑。

renderSuspenseBoundary 的主要逻辑为：

针对解析到的 Suspense 组件，创建一个新的 Boundary：newBoundary
新建一个 segment：boundarySegment， boundarySegment用于保存 Suspense 的 fallback 代表的内容，所以boundarySegment 的 boundary 属性值为 newBoundary 。同时， boundarySegment 也会保存到当前 task 的 blockedSegment的 children 属性中（可参考介绍 Segment 数据结构的例子）。
新建一个 segment：contentRootSegment ，保存 Suspense组件的children 代表的内容。
渲染 Suspense组件的children
如果渲染成功，说明 Suspense组件的 children没有需要异步等待的内容（渲染是同步完成的）：a. 设置contentRootSegment 的状态为 COMPLETEDb. 把 contentRootSegment存入newBoundary的completedSegments属性中
如果渲染过程 throw promise，说明 Suspense的 children 有需要异步等待的内容：a. 新建一个 task，task 的blockedBoundary等于 newBoundaryb. 当 promise resolve 后，将 task 保存到 request 的 pingedTasks 中（通过 task 的ping属性），等待下一个事件循环处理。c. 再新建一个 task，代表Suspense 的 fallback 组件树的渲染任务， task 的blockedSegment 等于 boundarySegment，task 的blockedBoundary 等于调用 renderSuspenseBoundary时的 task.blockedBoundary (不是 newBoundary，是 newBoundary 上一层级的 boundary)d. 把 task 保存到 request的 pingedTasks 中，等待在 performWork 中处理

这段逻辑比较复杂，简单理解的话，在渲染过程中，每当遇到 Suspense 组件，就会创建一个新的 Boundary，但新 Boundary 并不意味着一定要创建一个新的 Task，因为Suspense组件内元素的渲染不一定需要异步完成，只有存在动态导入组件（React.lazy）或获取异步数据等情况，才会创建一个新的 Task，用以表示这个异步的渲染过程。

上面的过程还有 2 个注意点：

步骤 6.a 中，新建的 task 不会立即放入 request的 pingedTasks 中，而是要等待代表异步任务的 promise resolve 后，才放入pingedTasks。所以pingedTasks ，实际上保存的是「没有异步任务依赖」的 task，是可以同步完成组件渲染工作的 task。
步骤 5 中，没有 6.c 和 6.d 两步，因为如果 Suspense 的 children 没有需要异步等待的内容，就不需要展示 fallback 内容，自然也不需要新建一个 task 负责 fallback 组件树的渲染任务。

3、启动输出流

renderToPipeableStream 返回 pipe 和 abort 2 个方法，分别用于向输出流写入组件树的渲染结果，和终止本次 SSR 请求。这里我们主要分析向输出流写入组件树的渲染结果。pipe 内部调用startFlowing，startFlowing 调用 flushCompletedQueues，flushCompletedQueues顾名思义，会将已完成的组件树的渲染信息，写入到输出流（Response）。

flushCompletedQueues 主要逻辑为：

检测 root boundary 范围的 tasks 是否已经渲染完成，如果是，则将对应的 segments 写入输出流；如果否，则返回（因为需要保证写入输出流的第一段数据，一定是 root boundary 范围内的组件的渲染结果）
检查 suspense boundaries ，如果 suspense boundary 满足条件：关联的所有 task 都已经完成，则将 suspense boundary 的 segment 写入输出流，suspense boundary 的完整内容在浏览器页面处于可见状态（不再显示 suspense 的 fallback 内容）。
继续检查 suspense boundaries，如果 suspense boundary 满足条件：存在完成的 task，但不是所有 task 都完成，则将这些完成的 task 的 segment 写入输出流，但 suspense boundary 的完整内容在浏览器页面仍然处于隐藏状态（包裹内容的 div 此时还是 hidden 状态）。
如果所有 suspense boundaries 的关联的 task 都已经完成，说明本次 SSR 完成，调用 close 结束请求。

flushCompletedQueues 简化后的代码如下：

function flushCompletedQueues(
  request: Request,
  destination: Destination,
): void {
    // 1.开始：root boundary 写入到输出流
    beginWriting(destination);
    let i;
    const completedRootSegment = request.completedRootSegment;
    if (completedRootSegment !== null) {
      // 将 root boundary 范围内的组件渲染结果写入输出流
      if (request.pendingRootTasks === 0) {
        flushSegment(request, destination, completedRootSegment);
        request.completedRootSegment = null;
        writeCompletedRoot(destination, request.responseState);
      } else {
        // root boundary 范围内，还存在没有完成的 task，直接返回。
        // 不需要继续向下看 suspense boundary 是否完成
        return;
      }
    }
    // 1.完成：root boundary 写入到输出流
    completeWriting(destination);
    // 2.开始：suspense boundary（关联的 task 已全部完成）写入到输出流
    beginWriting(destination);
    const completedBoundaries = request.completedBoundaries;
    for (i = 0; i < completedBoundaries.length; i++) {
      const boundary = completedBoundaries[i];
      if (!flushCompletedBoundary(request, destination, boundary)) {
        request.destination = null;
        i++;
        completedBoundaries.splice(0, i);
        return;
      }
    }
    completedBoundaries.splice(0, i);
    // 2.完成：suspense boundary（关联的 task 已全部完成）写入到输出流
    completeWriting(destination);
    // 3.开始：suspense boundary（关联的 task 部分完成）写入到输出流
    beginWriting(destination);
    const partialBoundaries = request.partialBoundaries;
    for (i = 0; i < partialBoundaries.length; i++) {
      const boundary = partialBoundaries[i];
      if (!flushPartialBoundary(request, destination, boundary)) {
        request.destination = null;
        i++;
        partialBoundaries.splice(0, i);
        return;
      }
    }
    partialBoundaries.splice(0, i);
    // 3.完成：suspense boundary（关联的 task 部分完成）写入到输出流
    completeWriting(destination);
    if (
      request.allPendingTasks === 0 &&
      request.pingedTasks.length === 0 &&
      request.clientRenderedBoundaries.length === 0 &&
      request.completedBoundaries.length === 0
    ) {
      // 所有渲染任务都已完成，关闭输出流
      close(destination);
    }
}

上面的代码中，一共有 3 组 beginWriting / completeWriting ，分别代表了 flushCompletedQueues 的前 3 步骤。

至此，我们就完成了 Streaming SSR 主要源码实现的分析。

以上就是React Streaming SSR原理示例深入解析的详细内容，更多关于React Streaming SSR的资料请关注我们其它相关文章！

React不使用requestIdleCallback实现调度原理解析

目录 1.起因 2.查找问题 3.解决问题 4.总结 5.吐槽 1.起因最近在一边啃源码,一边手写fiber嘛,然后也看了很多博客和资料,基本上大伙好像都是说用requestIdleCallback来模拟react实现一个空闲时间调度.但我自己手写的时候把怎么用怎么怪,老是感觉有什么地方不对劲而且是在调度过程中,可能是因为我是想写出来来一个相对健全一点的模版方便我以后写源码的其他部分把,然后分析了一下所以有了这篇博客. 2.查找问题 1.requestIdleCallback是利用帧之间空闲时
React classnames原理及测试用例

目录前言 classnames 的用法学会 classnames 的原理测试用例的使用总结前言本期的源码阅读任务是: 学会 classnames 的用法学会 classnames 的原理测试用例的使用源码地址:JedWatson/classnames: A simple javascript utility for conditionally joining classNames together (github.com) classnames 的用法 Classname 是一
React Context原理深入理解源码示例分析

目录正文一.概念二.使用 2.1.React.createContext 2.2.Context.Provider 2.3.React.useContext 2.4.Example 三.原理分析 3.1.createContext 函数实现 3.2. JSX 编译 3.3.消费组件 - useContext 函数实现 3.4.Context.Provider 在 Fiber 架构下的实现机制 3.5.小结四.注意事项五.对比 useSelector 正文在 React 中提供了一种「
React应用框架Dva数据流向原理总结分析

目录 Dva是什么? 流程图怎么看? Model对象属性数据流向 Dva是什么? 在刚刚接触Dva时,我最想知道的第一个问题就是: Dva官网文档的介绍是: dva 是体验技术部开发的 React 应用框架,将上面三个 React 工具库包装在一起,简化了 API,让开发 React 应用更加方便和快捷. dva = React-Router + Redux + Redux-saga 说实话这些名词让我只能一个一个的百度,虽然不能说毫无收获,但是依然难以理解. 现在我的理解Dva是一个轻量化的
React Hydrate原理源码解析

目录引言 Demo ReactDOM.render ReactDOM.hydrate hydrate 过程事件绑定 hydrate 源码剖析 beginWork HostRoot Fiber HostComponent HostText Fiber tryToClaimNextHydratableInstance completeUnitOfWork popHydrationState prepareToHydrateHostInstance prepareToHydrateHostText
React开发进阶redux saga使用原理详解

目录前言 redux的特点分析原理 1. 自动执行Generator 2. 发布订阅模式 3. put, takeEvery, delay, call返回effect 总结前言工作中使用了redux-saga这个redux中间件,如果不明白内部原理使用起来会让人摸不着头脑,阅读源码后特意对其原理做下总结. redux的特点一个标准.管理应用副作用的redux中间件实现切面编程方式声明式的编写方式订阅发布的设计模式优点: 把异步操作转移到单独 saga文件中,而不是糅杂在acti
React redux 原理及使用详解

目录概述 createStore创建store applyMiddleware 应用中间件 combineReducers 合并多个reducer dispatch 中间件中间件的调用顺序 store redux 数据流 bindActionCreators compose enhancer 使用 redux 常遇见的问题概述一个状态管理工具 Store:保存数据的地方,你可以把它看成一个容器,整个应用只能有一个 Store. State:包含所有数据,如果想得到某个时点的数据,就要对
React Streaming SSR原理示例深入解析

目录功能简介基本原理使用示例 Streaming HTML Selective Hydration 降级逻辑 JS 和 CSS 设置源码解析数据结构 Segment Boundary Task Request 主要流程功能简介 React 18 提供了一种新的 SSR 渲染模式: Streaming SSR.通过 Streaming SSR,我们可以实现以下两个功能: Streaming HTML:服务端可以分段传输 HTML 到浏览器,而不是像 React 18 以前一样,需要等待
react fiber执行原理示例解析

目录为什么要使用fiber,要解决什么问题? fiber是什么? 数据结构执行单元浏览器工作: Fiber执行原理 workInProgress tree: currentFiber tree: Effects list: render阶段: 遍历节点过程: 收集effect list: commit阶段: 为什么commit必须是同步的操作的? 为什么要使用fiber,要解决什么问题? 在 react16 引入 Fiber 架构之前,react 会采用递归方法对比两颗虚拟DOM树,找出需
useReducer createContext代替Redux原理示例解析

目录前言采用react-redux实现采用react hooks模拟redux实现异步action 总结前言最近看到很多采用useReducer + createContext 实现一个简易的redux的方案,今天亲自试了一下,发现还是会有一些区别的. 采用react-redux实现这里使用react-redux 实现一个简单的状态管理例子. App.jsx根组件 import React from 'react'; import { Button } from './Button
Kotlin协程之Flow基础原理示例解析

目录引言一.Flow的创建二.Flow的消费 1.SafeFlow类 2.AbstractFlow类 3. SafeCollector类 4.消费过程中的挂起引言本文分析示例代码如下: launch(Dispatchers.Main) { flow { emit(1) emit(2) }.collect { delay(1000) withContext(Dispatchers.IO) { Log.d("liduo", "$it") } Log.d(&qu
react hooks实现原理解析

目录 react hooks 实现 Hooks 解决了什么问题 Hooks API 类型首先接触到的是 State hooks 其次接触到的是 Effect hooks 最后接触到的是 custom hooks Hooks 实现方式问题一:useState dispatch 函数如何与其使用的 Function Component 进行绑定 react hooks 实现 Hooks 解决了什么问题在 React 的设计哲学中,简单的来说可以用下面这条公式来表示: UI = f(data)
react Suspense工作原理解析

目录 Suspense 基本应用 Suspense 原理基本流程源码解读 - primary 组件源码解读 - 异常捕获源码解读 - 添加 promise 回调源码解读-Suspense 首次渲染 primary 组件加载完成前的渲染 primary 组件加载完成时的渲染利用 Suspense 自己实现数据加载 Suspense 基本应用 Suspense 目前在 react 中一般配合 lazy 使用,当有一些组件需要动态加载(例如各种插件)时可以利用 lazy 方法来完成.其中
go语言csrf库使用实现原理示例解析

目录引言 csrf小档案一.CSRF及其实现原理 CSRF攻击示例二.如何预防三.CSRF包的使用及实现原理 csrf包的安装基本使用使用net/http包启动的服务 echo框架下使用csrf包 gin框架下使用csrf包 beego框架下使用csrf包实现原理 csrf结构体 csrf包的工作流程为什么GET.HEAD.OPTIONS.TRACE的请求方法不需要token验证总结引言今天给大家推荐的是web应用安全防护方面的一个包:csrf.该包为Go web应用中常见
flutter Bloc 实现原理示例解析

目录序言 1. 事件流 > 状态流 (中转) 2. 使用 BlocBuilder 实时监听状态变更, 如何实现的呢? 总结扩展序言在flutter开发中,我们使用 bloc 框架,基于状态变更进行响应式开发.本篇文章,小轰将 bloc 核心业务块进行拆解简化,聊一聊它的实现思想,bloc 核心能力分为如下两点: 添加事件 event,将 '事件流' 转换为 '状态流' state 监听 bloc 流,每次 state 状态变更,通知 widget 更新下面,用自定义Bloc的方式,来给
java LockSupport实现原理示例解析

目录引言 LockSupport常见函数 LockSupport.park LockSupport.unpark 引言前文中了解到AQS借助LockSupport.park和LockSupport.unpark完成线程的阻塞和唤醒,那么LockSupport内部又是怎么实现的?这是一个什么类? LockSupport是用于使用锁阻塞线程的基础实现,是其他同步类的基础,这个类为每个使用它的线程关联一个许可证(有点类似于Semaphore),如果许可证可用,线程调用park方法时会立即返回,线程
go sync Once实现原理示例解析

目录正文 Once 的实现使用示例 Once 的一些工作机制 Once 详解 hotpath atomic.LoadUint32 atomic.StoreUint32 Mutex 总结正文在很多情况下,我们可能需要控制某一段代码只执行一次,比如做某些初始化操作,如初始化数据库连接等. 对于这种场景,go 为我们提供了 sync.Once 对象,它保证了某个动作只被执行一次. 当然我们也是可以自己通过 Mutex 实现 sync.Once 的功能,但是相比来说繁琐了那么一点, 因为我们不仅