React Server Component

August 18, 2024 2 分钟阅读时间

React

目录 🔗︎

设计初衷
什么是 RSC？
如何实现 RSC？
核心方法解析
RSC 与 SSR 的关系
总结
React.use API
RSC 与 RCC 的区别
SSG、RSC 和 SSR 的对比
RSC 和 RCC 的交互规则
自定义标头 content-type: text/x-component
函数无法被序列化

设计初衷 🔗︎

React Server Components（RSC）的引入旨在提升 React 应用的性能和开发体验，主要体现在以下几个方面：

1. 减少客户端 JavaScript 负载 🔗︎

特点：RSC 允许开发者将部分逻辑留在服务器端执行，减少需要发送到客户端的 JavaScript 代码量。
优势：显著提升应用的加载性能，尤其对于大型应用或复杂页面。

2. 更高效的数据获取 🔗︎

特点：RSC 能够在服务器端直接获取数据并渲染组件。
优势：避免了客户端额外的网络请求，减少了延迟。

3. 优化 SEO 和初始加载性能 🔗︎

特点：初次加载时就能向客户端返回完整的 HTML 页面。
优势：搜索引擎更容易抓取内容，同时提升了用户的首次访问体验。

4. 提高开发体验 🔗︎

特点：可以在同一个项目中混合使用客户端组件和服务器组件。
优势：开发者可以根据需求灵活选择组件类型，简化开发流程。

5. 更好地利用服务器资源 🔗︎

特点：充分利用服务器的计算资源，减轻客户端设备的负担。
优势：特别适合移动设备或低性能设备用户，提供更流畅的体验。

什么是 RSC？ 🔗︎

通过服务端将 JSX（这里的 JSX 就是 RSC 组件）转换为 HTML，然后发送给客户端进行渲染。这就是服务端渲染（SSR）。
RSC 的核心思想是通过 JS 发送请求获取最新的区块 HTML，并通过水合替换区块内容。

特点 🔗︎

无感刷新：只更新特定区块的内容，其他区块的状态保持不变。
劫持 <a> 标签点击：通过 pushState 模拟页面刷新，结合 RSC 组件的方式替换刷新内容，从而实现无感替换。

如何实现 RSC？ 🔗︎

服务端渲染流程 🔗︎

字符串返回 HTML
正常情况下，服务端可以直接将 HTML 字符串返回给客户端。
使用 Babel 插件处理 JSX
- 使用 node-jsx-loader 插件，可以在服务端编写 JSX。
- 该插件会将 JSX 转换为一个 JS 对象（包含 type 和 props），这个对象可以进一步转换为 HTML 并发送给客户端。

核心方法解析 🔗︎

1. `renderJSXToClientJSX` 🔗︎

作用：服务端将 JSX 组件转换为 JSX 对象，然后将其序列化为 JSON 传递给客户端。
优势：客户端接收到 JSON 后，可以直接更新 DOM，无需重新加载整个页面。

2. `renderToString` 🔗︎

作用：将 JSX 转换为字符串形式的 HTML，发送到浏览器后由客户端进行水合（Hydration）。
适用场景：适用于传统的 SSR 场景。

RSC 与 SSR 的关系 🔗︎

独立但可结合
服务器组件（RSC）和服务器渲染（SSR）是两种独立的技术，但它们可以结合使用，构建跨服务器和客户端的应用程序。
区别
- SSR：产出的是 HTML。
- RSC：产出的是指令，用于指导客户端如何更新特定区块的内容。

总结 🔗︎

React Server Components 的引入为现代 Web 应用带来了诸多优势：

减少了客户端 JavaScript 的负载，提升了加载性能。
在服务器端完成数据获取和渲染，优化了用户体验。
支持无感刷新和状态保持，增强了交互体验。
灵活的开发模式允许开发者根据需求自由选择组件类型。

通过 renderJSXToClientJSX 和 renderToString 等核心方法，RSC 实现了高效的跨端协作。未来，随着技术的不断发展，RSC 将继续为开发者提供更强大的工具来构建高性能、高体验的 Web 应用。

React.use API 🔗︎

概述：
React.use API 可以让组件在服务端和客户端之间实现同构渲染，并自动回退到 CSR（客户端渲染）。

案例：
适用于 RSC（React Server Components）场景。

RSC 与 RCC（React Client Component) 的区别 🔗︎

概念	描述
RSC	从后端获取数据的组件，通常用于服务端渲染。
RCC	包含数据的可交互组件，通常运行在客户端，支持用户交互。

案例：
RSC 和 RCC 是 React Server Components 中的核心概念，分别负责服务端和客户端的职责划分。

SSG、RSC 和 SSR 的对比 🔗︎

方案	描述
SSG	编译时方案，在构建阶段生成静态 HTML 文件。
RSC	运行时方案，输出类 JSON 数据结构，支持流式传输。
SSR	运行时方案，输出完整的 HTML 文件。

特点：

RSC 和 SSR 可以同时存在。
SSG 更适合静态内容，RSC 和 SSR 更适合动态内容。

案例：
RSC 的流式输出可以显著提升首屏加载性能，同时支持动态数据更新。

RSC 和 RCC 的交互规则 🔗︎

规则	描述
RSC 和 RCC	可以交替出现，但 RCC 不能直接 import RSC。
RSC 使用 RCC	RSC 可以通过 `children` 方式使用 RCC，因为运行时 RCC 可以获取到数据。

补充说明：
这种设计确保了服务端和客户端之间的职责分离，同时允许灵活的组件组合。

自定义标头 `content-type: text/x-component` 🔗︎

概述：
content-type: text/x-component 是一种自定义标头，用于标识 RSC 的响应数据格式。

用途：

区分普通的 HTML 或 JSON 响应。
确保客户端能够正确解析 RSC 的流式数据。

案例：
在 RSC 场景中，服务器返回的数据会带有该标头，以便客户端识别并处理。

函数无法被序列化 🔗︎

问题描述：
在 JavaScript 中，函数无法通过 JSON.stringify 序列化。

示例代码：

const obj = {
  name: 'John',
  age: 30,
  sayHello: function() {
    console.log('Hello!');
  }
};

const json = JSON.stringify(obj);
console.log(json); // 输出：{"name":"John","age":30}

原因分析：
JSON.stringify 只能序列化对象中的基本数据类型（如字符串、数字、布尔值等），无法处理函数或方法。

应用场景：
在 RSC 的序列化协议中，需要特别注意避免传递包含函数的对象，否则会导致数据丢失或错误。