React Server Components 札记

[xxleyi]

React 团队又搞了个重磅炸弹：服务端组件，React Server Components。

下面是一些个人的理解与思考。

什么是 RSC 呢？就是某种类型的组件在服务器上就被 render 掉，产出是 React runtime 可以理解的「某种描述 UI 的数据」，然后通过网络请求发给客户端，客户端上的 React runtime 会把这种描述 UI 的数据严丝合缝的嵌入到客户端已有的 UI 数据中，最终渲染成真实的浏览器 DOM 结构，交由浏览器进一步渲染成用户肉眼可见的 UI。

早在 React 之前，传统的服务端就可以通过 template 动态生成 HTML（这是浏览器可以直接理解的一种描述 UI 的数据）， 然后将 HTML 发给浏览器，然后浏览器将其渲染为真实的浏览器 DOM 结构，并进一步渲染成用户肉眼可见的 UI。

在 React 这类聚焦客户端渲染的前端框架横扫 Web 前端的同时，人们依然有着服务端渲染的需求，这就是 SSR，一般是为了加快首屏渲染速度和搜索上的 SEO 优化。其背后的技术底子也是先在服务端渲染出 HTML。

RSC 和这些已有的技术是不是很像？确实比较像，但又有微妙而本质的区别。服务端通过 template 动态生成 HTML 文件时，会阻塞式的访问数据库，得到各种最新数据，然后将其填充到 template 中，从而生成 HTML 格式的数据。HTML 是静态 UI，而且浏览器只能使用覆盖式更新的方式渲染最新的 HTML 数据。

RSC 呢？服务端渲染自定义的组件，产出是 React 自己可以进一步消费的「某种描述 UI 的数据」，与 HTML 的本质不同在于，它包含更多信息量，可以降维到 HTML，意思是 SSR 的能做的，RSC 也能做，但真正的杀手锏是：它可以和客户端现有的状态组件进行合并渲染，更新 UI 的同时，保留客户端现有 state。

本质上，RSC 的到来，意味着 UI = f(data) 这一 React 的核心设计正式打通客户端和服务端。注意，不是简单的支持服务端，而是将客户端和服务端联合在一起：组件不再受限于客户端或服务端，而是可以自由移动，当然需要付出一些精力进行合理改造。但好消息是，据 Facebook 自己内部的实践结果看，共享组件的比例是绝对的大头，而共享组件是无需额外努力，就可以在客户端和服务端之间自由移动的一类组件。这类组件既没有自己的 state，也不需要使用外部数据源，看似是无名之辈，但数量却最为庞大。

RSC 的到来，也让我们可以重新审视组件中的 props 和 state：

• 在现有 React 组件系统中，只有客户端组件，我们往往使用 effects 来动态获取服务端的数据，然后将其放置在某个 state 中，通过 props 一路向下传递
• 如果是使用 RSC 的话，可以直接在服务端获取数据，然后将其直接作为 props 一路向下传递
• 组件系统细分为服务端组件，客户端组件，共享组件，确实有很多限制，但我们有自行调整组件类型的全部自由
• 由此带来的效果是：静态的和拉取数据的部分可以走服务端渲染，带有交互的动态部分走客户端渲染，而共享部分在服务端使用时就在服务端渲染，在客户端使用时，就使用客户端渲染。任何一个组件，如果由静变动，则意味着渲染环境由服务端变为客户端，如果由动变静，则意味着渲染环境由客户端变为服务端
• 只有客户端组件才能拥有 state，服务端组件和共享组件不能拥有自己的 state，但服务端组件可以通过 IO 行为获取服务端数据，共享组件既没有 state，也没有 IO 行为，是签名为 props => elements 的纯函数

换言之：因为 RSC 的到来，将会有相当一部分的 state 能够直接以 props 的形式存在，而无需在客户端通过 useEffect 或 componentDidMount 进行一次中转。组件可以在客户端和服务端之间的自由流动，直接体现在 state 和 props 之间的自由流动。

不得不感叹，聚焦于 UI = f(data) 的 React 坚持为自己和开发者保留足够的自由，坚决不引入任何非必要的语法糖和小打小闹式的优化，潜心搞大事情。于是，搞出了 hooks，搞出了 fiber 渲染引擎下的并发模式，搞出了并发模式下的服务端组件，但这所有的一切依旧在 UI = f(data) 这个核心的数据转换之内，在严格保留强一致性的基础上，扩宽自由边界的同时，也提供了越来越友好、顺畅的开发体验。

React 抓住数据转换这一核心，围绕这个核心的数据转换设计并实现一系列的编程方案，UI 中最关键的 state 部分从最开始寄居在 class 实例，到后来寄居于 React Fiber 节点，到现在其中的一部分又可以直接寄居于服务端的持久化存储系统中，比如 Redis, MySQL, MongoDB, 甚至 filesystem 和其它后端服务的数据 API。

至此我们也可以发现，state 无非就是两类：

• 用户操作产生的纯表现层相关的 state，如选择列表是否展开，选项是否选中，当前的滚动位置，当前被选中的文本，当前输入框中的数据，以及各种字体大小，背景颜色，甚至动画。
• 用户操作产生的持久化数据，如已经上传完成的头像，已经完成的商品交易，已经发布的文章，已经发布的评论，这些数据往往在用户完成操作的瞬间，已经持久化到服务端文件系统或者数据库中。需要呈现的时候，也只能将持久化数据取出来，作为 props 入参（在客户端组件中，需要借助 state 进行一次中转），呈现在用户的 UI 之中。

这两类正好完美对应客户端和服务端。整个 Web 的发展历史也像一个钟摆：

• 一开始客户端 state 部分为零，只是渲染 HTML 文档
• 然后浏览器加入支持客户端 state 的 JS 脚本，某一天 JQuery 横空出世，客户端 state 大放异彩，交互复杂度陡升
• 然后有了 React 这种专注于客户端渲染的库或框架，将原本服务端处理的渲染部分一并强夺过来，钟摆从后端彻底摆到前端一侧
• 但客户端并不是处理服务端渲染的最佳场所，现在的局面是钟摆在慢慢摆向中间
• 但开发者的摆动已经不可逆，后端越来越靠后，前端也越来越靠后，前端开发对全栈的要求越来越高

总结：RSC 给了开发者把一部分 state 放到服务端处理的能力和自由，代价就是耗费更多服务器资源和更多的心智负担。