您现在的位置是：首页 > 编程语言学习 > 后端编程语言 > 文章正文 后端编程语言

React Streaming SSR原理示例深入解析

2022-12-20 10:29:30 后端编程语言

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

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 为例）如下：

  1. let didError = false; 
  2. const stream = renderToPipeableStream( 
  3.   <App />, 
  4.   {  
  5. bootstrapScripts: ["main.js"], 
  6. onShellReady() { 
  7.   // The content above all Suspense boundaries is ready. 
  8.   // If something errored before we started streaming,  
  9.   // we set the error code appropriately. 
  10.   res.statusCode = didError ? 500 : 200; 
  11.   res.setHeader('Content-type', 'text/html'); 
  12.   stream.pipe(res); 
  13. }, 
  14. onShellError(error) { 
  15.   // Something errored before we could complete the shell  
  16.   // so we emit an alternative shell. 
  17.   res.statusCode = 500; 
  18.   res.send('<!doctype html><p>Loading...</p><script src="clientrender.js"></script>'); 
  19. }, 
  20. onAllReady() { 
  21.   // stream.pipe(res); 
  22. }, 
  23. onError(err) { 
  24.   didError = true; 
  25.   console.error(err); 
  26. } 
  27.   } 
  28. ); 

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

Streaming HTML

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

  1. const http = require("http"); 
  2. const url = require("url"); 
  3. const sleep = (ms) => { 
  4.   return new Promise((resolve) => { 
  5. setTimeout(resolve, ms); 
  6.   }); 
  7. }; 
  8. const server = http.createServer(async (req, res) => { 
  9.   const { pathname } = url.parse(req.url); 
  10.   if (pathname === "/") { 
  11. res.statusCode = 200; 
  12. res.setHeader("Content-Type", "text/html"); 
  13. res.setHeader("Transfer-Encoding", "chunked"); 
  14. res.write("<html><body><div>First segment</div>"); 
  15. // 手动设置延时，让分段显示的效果更加明显 
  16. await sleep(2000); 
  17. res.write("<div>Second segment</div></body></html>"); 
  18. res.end(); 
  19. return; 
  20.   } 
  21.   res.writeHead(200, { "Content-Type": "text/plain" }); 
  22.   res.end("okay"); 
  23. }); 
  24. server.listen(8080); 

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

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

  1. //文件1： Content.js 
  2. export default function Content() { 
  3.   return ( 
  4. <div> This is content </div> 
  5.   ); 
  6. } 
  7. // 文件2：App.js 
  8. import { Suspense, lazy } from "react"; 
  9. const Content = lazy(() => import("./Content")); 
  10. export default function App() { 
  11.   return ( 
  12. <html> 
  13.   <head></head> 
  14.   <body> 
  15. <div>App shell</div> 
  16. <Suspense> 
  17.   <Content /> 
  18. </Suspense> 
  19.   </body> 
  20. </html> 
  21.   ); 
  22. }` 

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

  1. <!DOCTYPE html> 
  2. <html> 
  3.    <head></head> 
  4.    <body> 
  5.   <div>App shell</div> 
  6.   <!--$?--> 
  7.   <template id="B:0"></template> 
  8.   <!--/$--> 
  9.    </body> 
  10. </html> 

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

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

  1. <div hidden id="S:0">  
  2.   <div> This is content </div> 
  3. </div> 
  4. <script>  
  5.   function $RC(a, b) { 
  6. a = document.getElementById(a); 
  7. b = document.getElementById(b); 
  8. b.parentNode.removeChild(b); 
  9. if (a) { 
  10. a = a.previousSibling; 
  11. var f = a.parentNode, 
  12. c = a.nextSibling, 
  13. e = 0; 
  14. do { 
  15. if (c && 8 === c.nodeType) { 
  16. var d = c.data; 
  17. if ("/$" === d) 
  18. if (0 === e) break; 
  19. else e--; 
  20. else "$" !== d && "$?" !== d && "$!" !== d || e++ 
  21. } 
  22. d = c.nextSibling; 
  23. f.removeChild(c); 
  24. c = d 
  25. } while (c); 
  26. for (; b.firstChild;) f.insertBefore(b.firstChild, c); 
  27. a.data = "$"; 
  28. a._reactRetry && a._reactRetry() 
  29. } 
  30.   }; 
  31.   $RC("B:0", "S:0")  
  32. </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获取数据：

  1. let data; 
  2. const getData = () => { 
  3.   if (!data) { 
  4. data = new Promise((resolve) => { 
  5.   // 延迟 2s 返回数据 
  6.   setTimeout(() => { 
  7. data = "content from remote"; 
  8. resolve(); 
  9.   }, 2000); 
  10. }); 
  11. throw data; 
  12.   } 
  13.   // promise-like 
  14.   if (data && data.then) { 
  15. throw data; 
  16.   } 
  17.   const result = data; 
  18.   data = undefined; 
  19.   return result; 
  20. }; 
  21. export default function Content() { 
  22.   // 获取异步数据 
  23.   const data = getData(); 
  24.   return <div>{data}</div>; 
  25. } 

这样，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 提供了一个 APIloadableReady，在等待 JS bundle 加载完成后，才执行 hydration 。示意代码如下：

  1. loadableReady(function(){ 
  2.   hydrateRoot(root, <App/>) 
  3. }) 

如果在没有等待所有的 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：

  1. import {lazy, Suspense} from 'react' 
  2. const Content = lazy(() => import("./Content")); 
  3. export default function App() { 
  4.   return ( 
  5. <html> 
  6.   <head></head> 
  7.   <body> 
  8. <div>App shell</div> 
  9. <Suspense> 
  10.   <Content /> 
  11. </Suspense> 
  12.   </body> 
  13. </html> 
  14.   ); 
  15. } 

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

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

  1. import {lazy, Suspense, useState} from 'react' 
  2. // 同步导入 Content 组件 
  3. import Content from './Content'; 
  4. const Sidebar = () => { 
  5.   const [color, setColor] = useState('black'); 
  6.   return ( 
  7. <div className="home"> 
  8.   <div style={{ color }}>Siderbar</div> 
  9.   <button 
  10. onClick={() => { 
  11.   setColor(color === 'black' ? 'red' : 'black'); 
  12. }} 
  13.   > 
  14. change 
  15.   </button> 
  16. </div> 
  17.   ); 
  18. }; 
  19. export default function App() { 
  20.   return ( 
  21. <html> 
  22.   <head></head> 
  23.   <body> 
  24. <div>App shell</div> 
  25. <Sidebar /> 
  26. <Suspense> 
  27.   <Content /> 
  28. </Suspense> 
  29.   </body> 
  30. </html> 
  31.   ); 
  32. } 

访问页面时，在渲染出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 阶段抛出异常：

  1. export default function Content() { 
  2.   const _data = getData(); 
  3.   // 制造异常 
  4.   if(typeof window === 'undefined'){ 
  5. data = undefined 
  6. throw Error('SSR Error') 
  7.   } 
  8.   return ( 
  9. <div> 
  10.   {_data} 
  11. </div> 
  12.   ); 
  13. } 

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

  1. <script> 
  2.   function $RX(b, c, d, e) { 
  3. var a = document.getElementById(b); 
  4. b = a.previousSibling; 
  5. b.data = "$!"; 
  6. a = a.dataset; 
  7. c && (a.dgst = c); 
  8. d && (a.msg = d); 
  9. e && (a.stck = e); 
  10. b._reactRetry && b._reactRetry() 
  11.   }; 
  12.   $RX("B:0", "", "SSR Error", "\nat Content\nat Lazy\nat Content\nat Lazy\nat Suspense\nat body\nat html\nat App\nat DataProvider (/Users/bytedance/work/examples/stream-ssr-demo/src/data.js:18:23)")  
  13.  </script> 

第二段数据中返回了RX函数，而不是渲染正确情况下的RX函数，而不是渲染正确情况下的 RX函数，而不是渲染正确情况下的RC函数。RX会将渲染出错的Suspense在HTML中对应的Comment标签<!−−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 。

  1.  let didError = false; 
  2.  const stream = renderToPipeableStream( 
  3. <App assets={assets} />, 
  4. { 
  5.   onShellReady() { 
  6. // If something errored before we started streaming, we set the error code appropriately. 
  7. res.statusCode = didError ? 500 : 200; 
  8. res.setHeader("Content-type", "text/html"); 
  9. stream.pipe(res); 
  10.   }, 
  11.   onError(x) { 
  12. didError = true; 
  13. console.error(x); 
  14.   }, 
  15.   onShellError(x) { 
  16. didError = true; 
  17. res.send(<html>...</html>)//返回 CSR 使用的 HTML 模版，整棵组件树降级到 CSR   
  18.   } 
  19. } 
  20.   ); 

JS 和 CSS 设置

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

在 HTML 组件中设置示例如下：
  1. function Html({ assets, children, title }) { 
  2. return ( 
  3.   <html> 
  4. <head> 
  5.   <title>{title}</title> 
  6.   <link rel="stylesheet" href={assets["main.css"]} /> 
  7.   <script src={assets["main.js"]}></script> 
  8. </head> 
  9. <body> 
  10.   <noscript 
  11. dangerouslySetInnerHTML={{ 
  12.   __html: `<b>Enable JavaScript to run this app.</b>` 
  13. }} 
  14.   /> 
  15.   {children} 
  16.   <script 
  17. dangerouslySetInnerHTML={{ 
  18.   __html: `assetManifest = ${JSON.stringify(assets)};` 
  19. }} 
  20.   /> 
  21. </body> 
  22.   </html> 
  23. ); 
  24.   } 
  25. function App({assets}) { 
  26.    return ( 
  27.  <Html assets={assets} title="Hello"> 
  28. {/* other components */} 
  29.  </Html> 
  30.    ); 
  31.  } 
  32.   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 返回的第一段数据中。 示例如下：
  1. import { Transform } from 'stream'; 
  2. // 代表传输的第一段数据 
  3. let isShellStream = true; 
  4. const injectTemplateTransform = new Transform({ 
  5.   transform(chunk, _encoding, callback) { 
  6. if (isShellStream) { 
  7.   // headTpl 代表 <html><head>...</head><body><div id='root'> 部分的模版 
  8.   // tailTpl 代表 </div></body></html> 部分的模版 
  9.   this.push(`${headTpl}${chunk.toString()}${tailTpl}`)); 
  10.   isShellStream = false; 
  11. } else { 
  12.   this.push(chunk); 
  13. } 
  14. callback(); 
  15.   }, 
  16. }); 
  17. const stream = renderToPipeableStream( 
  18.   <App />, 
  19.   {  
  20. onShellReady() { 
  21.   res.setHeader('Content-type', 'text/html'); 
  22.   stream.pipe(injectTemplateTransform).pipe(res); 
  23. }, 
  24.   } 
  25. ); 

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

通过参数bootstrapScripts设置通过renderToPipeableStream的第二个参数，设置bootstrapScripts的值，``bootstrapScripts` 的值为 HTML 所需的 JS 文件路径。注意，这种方式不支持设置 CSS 文件。 示例如下：
  1. const stream = renderToPipeableStream( 
  2.   <App />, 
  3.   {  
  4. bootstrapScripts: ["main.js"], 
  5. onShellReady() { 
  6.   res.setHeader('Content-type', 'text/html'); 
  7.   stream.pipe(res); 
  8. }, 
  9.   } 
  10. ); 

源码解析

数据结构

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

Segment

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

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

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

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

children

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

  1. import { lazy } from 'react' 
  2. const Content = lazy(() => import('./Content' )); 
  3. function App = (props) => { 
  4.   return ( 
  5. <div> 
  6.   <div>App</div>  
  7.   <Suspense fallback={<Spinner />}> 
  8.  <Content /> 
  9.   </Suspense> 
  10. </div> 
  11.   ) 
  12. } 

React 会创建 3 个 Segment：

Segment 1 对应的 DOM 结构为：




	
    
	
  1. <div> 
    2. 
	
  2.   <div>App<div/>  
    3. 
	
  3. </div> 
    4. 
	





	
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 个元素示意：



	
    
	
  1. [0]: <div> 
    2. 
	
  2. [1]: <div>App</div>  
    3. 
	
  3. [2]: </div> 
    4. 
	




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


Boundary


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


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



	
    
	
  1. import { lazy } from 'react' 
    2. 
	
  2. const Content = lazy(() => import('./Content' )); 
    3. 
	
  3. const Comments = lazy(() => import('./Comments' )); 
    4. 
	
  4. function App = (props) => { 
    5. 
	
  5.   return ( 
    6. 
	
  6. <div> 
    7. 
	
  7.   <div>App<div/>  
    8. 
	
  8.   {/* Boundary 1 */} 
    9. 
	
  9.   <Suspense fallback={<Spinner />}> 
    10. 
	
  10.  <Content /> 
    11. 
	
  11.  {/* Boundary 2 */} 
    12. 
	
  12.  <Suspense fallback={<Spinner />}> 
    13. 
	
  13.    <Comments /> 
    14. 
	
  14.  </Suspense> 
    15. 
	
  15.   </Suspense> 
    16. 
	
  16. </div> 
    17. 
	
  17.   ) 
    18. 
	
  18. } 
    19. 
	




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



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




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组件内的组件树的异步渲染任务。


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



	
    
	
  1. import { lazy } from 'react' 
    2. 
	
  2. const Content = lazy(() => import('./Content' )); 
    3. 
	
  3. function App = (props) => { 
    4. 
	
  4.   return ( 
    5. 
	
  5. <div> 
    6. 
	
  6.   <div>App</div>  
    7. 
	
  7.   <Suspense fallback={<Spinner />}> 
    8. 
	
  8.  <Content /> 
    9. 
	
  9.   </Suspense> 
    10. 
	
  10. </div> 
    11. 
	
  11.   ) 
    12. 
	
  12. } 
    13. 
	




在 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 类型及字段说明如下：



	
    
	
  1. type Request = { 
    2. 
	
  2.   // 请求结果的输出流，即 Response 对象 
    3. 
	
  3.   destination: null | Destination, 
    4. 
	
  4.   // 所有未完成的 Task 数量，当等于 0 时，表示本次 SSR 完成，可以关闭 HTTP 连接 
    5. 
	
  5.   allPendingTasks: number,  
    6. 
	
  6.   // Root Boundary 范围内的未完成的 Task 数量，当等于 0 时，Root Boundary 渲染完成 
    7. 
	
  7.   pendingRootTasks: number,  
    8. 
	
  8.   // 等待执行的 Task 
    9. 
	
  9.   pingedTasks: Array<Task>, 
    10. 
	
  10.   // 已完成的 Root Segment  
    11. 
	
  11.   completedRootSegment: null | Segment,  
    12. 
	
  12.   // 已完成的 Boundary  
    13. 
	
  13.   completedBoundaries: Array<SuspenseBoundary>,  
    14. 
	
  14.   // Root Boundary 渲染完成后的回调 
    15. 
	
  15.   onShellReady: () => void, 
    16. 
	
  16.   // Root Boundary 渲染过程中，出错的回调 
    17. 
	
  17.   onShellError: (error: mixed) => void, 
    18. 
	
  18.   // 所有 Boundary 都渲染完成，即 SSR 完成的回调 
    19. 
	
  19.   onAllReady: () => void, 
    20. 
	
  20.   // Root Boundary 渲染完成后，在后续 Suspense Boundary 渲染过程中出错的回调 
    21. 
	
  21.   onError: (error: mixed) => ?string, 
    22. 
	
  22. }; 
    23. 
	




主要流程


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




renderToPipeableStream的关键代码如下：



	
    
	
  1. function renderToPipeableStream( 
    2. 
	
  2.   children: ReactNodeList, 
    3. 
	
  3.   options?: Options, 
    4. 
	
  4. ): PipeableStream { 
    5. 
	
  5.   // 创建请求对象 Request 
    6. 
	
  6.   const request = createRequest(children, options); 
    7. 
	
  7.   // 启动组件树的渲染任务 
    8. 
	
  8.   startWork(request); 
    9. 
	
  9.   return { 
    10. 
	
  10. pipe<T: Writable>(destination: T): T { 
    11. 
	
  11.   // 开始将渲染结果写入输出流  
    12. 
	
  12.   startFlowing(request, destination); 
    13. 
	
  13.   return destination; 
    14. 
	
  14. }, 
    15. 
	
  15. abort(reason: mixed) { 
    16. 
	
  16.   abort(request, reason); 
    17. 
	
  17. }, 
    18. 
	
  18.   }; 
    19. 
	
  19. } 
    20. 
	




为了便于理解主干流程，本节列出的 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 将作为后续渲染操作的起点



	
    
	
  1. export function createRequest( 
    2. 
	
  2.   children: ReactNodeList, 
    3. 
	
  3.   options?: Options, 
    4. 
	
  4. ): Request { 
    5. 
	
  5.   const pingedTasks = []; 
    6. 
	
  6.   const request = { 
    7. 
	
  7. //  初始化 request 
    8. 
	
  8.   }; 
    9. 
	
  9.   // This segment represents the root fallback. 
    10. 
	
  10.   const rootSegment = { 
    11. 
	
  11. status: PENDING, 
    12. 
	
  12. index: 0, 
    13. 
	
  13. chunks: [], 
    14. 
	
  14. children: [], 
    15. 
	
  15.   }; 
    16. 
	
  16.   const rootTask = createTask( 
    17. 
	
  17. request, 
    18. 
	
  18. children, 
    19. 
	
  19. null, 
    20. 
	
  20. rootSegment 
    21. 
	
  21.   ); 
    22. 
	
  22.   pingedTasks.push(rootTask); 
    23. 
	
  23.   return request; 
    24. 
	
  24. } 
    25. 
	




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


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



	
    
	
  1. function createTask( 
    2. 
	
  2.   request: Request, 
    3. 
	
  3.   node: ReactNodeList, 
    4. 
	
  4.   blockedBoundary: Root | SuspenseBoundary, 
    5. 
	
  5.   blockedSegment: Segment, 
    6. 
	
  6. ): Task { 
    7. 
	
  7.   // allPendingTasks 自增 1 
    8. 
	
  8.   request.allPendingTasks++; 
    9. 
	
  9.   // 如果是 root boundary, pendingRootTasks 自增1； 
    10. 
	
  10.   // 否则把对应 boundary 范围里的 pendingTask 自增1 
    11. 
	
  11.   if (blockedBoundary === null) { 
    12. 
	
  12. request.pendingRootTasks++; 
    13. 
	
  13.   } else { 
    14. 
	
  14. blockedBoundary.pendingTasks++; 
    15. 
	
  15.   } 
    16. 
	
  16.   // 创建 task，ping 的作用后续介绍 
    17. 
	
  17.   const task: Task = ({ 
    18. 
	
  18. node, 
    19. 
	
  19. ping: () => pingTask(request, task), 
    20. 
	
  20. blockedBoundary, 
    21. 
	
  21. blockedSegment, 
    22. 
	
  22.   }: any); 
    23. 
	
  23.   return task; 
    24. 
	
  24. } 
    25. 
	




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


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



	
    
	
  1. export function performWork(request: Request): void { 
    2. 
	
  2.   const pingedTasks = request.pingedTasks; 
    3. 
	
  3.   let i; 
    4. 
	
  4.   for (i = 0; i < pingedTasks.length; i++) { 
    5. 
	
  5. const task = pingedTasks[i]; 
    6. 
	
  6. retryTask(request, task); 
    7. 
	
  7.   } 
    8. 
	
  8.   pingedTasks.splice(0, i); 
    9. 
	
  9.   if (request.destination !== null) { 
    10. 
	
  10. flushCompletedQueues(request, request.destination); 
    11. 
	
  11.   } 
    12. 
	
  12. } 
    13. 
	




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主要代码如下：



	
    
	
  1. function retryTask(request: Request, task: Task): void { 
    2. 
	
  2.   const segment = task.blockedSegment; 
    3. 
	
  3.   try { 
    4. 
	
  4. renderNodeDestructive(request, task, task.node); 
    5. 
	
  5. segment.status = COMPLETED; 
    6. 
	
  6. finishedTask(request, task.blockedBoundary, segment); 
    7. 
	
  7.   } catch (x) { 
    8. 
	
  8. resetHooksState(); 
    9. 
	
  9. if (typeof x === 'object' && x !== null && typeof x.then === 'function') { 
    10. 
	
  10.   // Something suspended again, let's pick it back up later. 
    11. 
	
  11.   const ping = task.ping; 
    12. 
	
  12.   x.then(ping, ping); 
    13. 
	
  13. } 
    14. 
	
  14.   } 
    15. 
	
  15. } 
    16. 
	




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



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





	
    
	
  1. function pingTask(request: Request, task: Task): void { 
    2. 
	
  2.   const pingedTasks = request.pingedTasks; 
    3. 
	
  3.   pingedTasks.push(task); 
    4. 
	
  4.   scheduleWork(() => performWork(request)); 
    5. 
	
  5. } 
    6. 
	




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和abort2 个方法，分别用于向输出流写入组件树的渲染结果，和终止本次 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简化后的代码如下：



	
    
	
  1. function flushCompletedQueues( 
    2. 
	
  2.   request: Request, 
    3. 
	
  3.   destination: Destination, 
    4. 
	
  4. ): void { 
    5. 
	
  5. // 1.开始：root boundary 写入到输出流 
    6. 
	
  6. beginWriting(destination); 
    7. 
	
  7. let i; 
    8. 
	
  8. const completedRootSegment = request.completedRootSegment; 
    9. 
	
  9. if (completedRootSegment !== null) { 
    10. 
	
  10.   // 将 root boundary 范围内的组件渲染结果写入输出流 
    11. 
	
  11.   if (request.pendingRootTasks === 0) { 
    12. 
	
  12. flushSegment(request, destination, completedRootSegment); 
    13. 
	
  13. request.completedRootSegment = null; 
    14. 
	
  14. writeCompletedRoot(destination, request.responseState); 
    15. 
	
  15.   } else { 
    16. 
	
  16. // root boundary 范围内，还存在没有完成的 task，直接返回。 
    17. 
	
  17. // 不需要继续向下看 suspense boundary 是否完成 
    18. 
	
  18. return; 
    19. 
	
  19.   } 
    20. 
	
  20. } 
    21. 
	
  21. // 1.完成：root boundary 写入到输出流 
    22. 
	
  22. completeWriting(destination); 
    23. 
	
  23. // 2.开始：suspense boundary（关联的 task 已全部完成）写入到输出流 
    24. 
	
  24. beginWriting(destination); 
    25. 
	
  25. const completedBoundaries = request.completedBoundaries; 
    26. 
	
  26. for (i = 0; i < completedBoundaries.length; i++) { 
    27. 
	
  27.   const boundary = completedBoundaries[i]; 
    28. 
	
  28.   if (!flushCompletedBoundary(request, destination, boundary)) { 
    29. 
	
  29. request.destination = null; 
    30. 
	
  30. i++; 
    31. 
	
  31. completedBoundaries.splice(0, i); 
    32. 
	
  32. return; 
    33. 
	
  33.   } 
    34. 
	
  34. } 
    35. 
	
  35. completedBoundaries.splice(0, i); 
    36. 
	
  36. // 2.完成：suspense boundary（关联的 task 已全部完成）写入到输出流 
    37. 
	
  37. completeWriting(destination); 
    38. 
	
  38. // 3.开始：suspense boundary（关联的 task 部分完成）写入到输出流 
    39. 
	
  39. beginWriting(destination); 
    40. 
	
  40. const partialBoundaries = request.partialBoundaries; 
    41. 
	
  41. for (i = 0; i < partialBoundaries.length; i++) { 
    42. 
	
  42.   const boundary = partialBoundaries[i]; 
    43. 
	
  43.   if (!flushPartialBoundary(request, destination, boundary)) { 
    44. 
	
  44. request.destination = null; 
    45. 
	
  45. i++; 
    46. 
	
  46. partialBoundaries.splice(0, i); 
    47. 
	
  47. return; 
    48. 
	
  48.   } 
    49. 
	
  49. } 
    50. 
	
  50. partialBoundaries.splice(0, i); 
    51. 
	
  51. // 3.完成：suspense boundary（关联的 task 部分完成）写入到输出流 
    52. 
	
  52. completeWriting(destination); 
    53. 
	
  53. if ( 
    54. 
	
  54.   request.allPendingTasks === 0 && 
    55. 
	
  55.   request.pingedTasks.length === 0 && 
    56. 
	
  56.   request.clientRenderedBoundaries.length === 0 && 
    57. 
	
  57.   request.completedBoundaries.length === 0 
    58. 
	
  58. ) {   
    59. 
	
  59.   // 所有渲染任务都已完成，关闭输出流 
    60. 
	
  60.   close(destination); 
    61. 
	
  61. } 
    62. 
	
  62. } 
    63. 
	




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


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

			
			

			
			

									
					React 
							

			
			

			
			

			

				

					上一篇：AJAX请求与跨域问题解决方法详解
				

				

					下一篇：最后一页
				

			

		

	

	
	
	

		
相关文章

				
	

	




		
		

			
点击排行

							
					

		
		

			
站长推荐

							
					

		

			
标签云

				
		

		
		

			
猜你喜欢

						
					

		
		

			
站点信息