在过去十年中，React 一直是构建网络应用程序的强大工具。
我们都见证了它从笨拙的类组件发展到优雅的钩子。
但是 React 服务器组件（RSC）呢？
我们认为没有人会想到 React 的工作方式会发生如此巨大的转变。
那么，React 服务器组件到底是什么？它们如何工作？它们有哪些不同于 React 的功能？
为了回答所有这些问题，我们将快速回顾一下基本原理。如果您需要复习，请查看了解 React 学习资源。
在本篇文章中，我们将带您了解为什么需要 React 服务器组件、它们是如何工作的，以及 RSC 的一些主要优势。
什么是 React 服务器组件？
React 服务器组件是构建 React 应用程序的一种新方式。React 服务器组件不像典型的 React 组件那样在浏览器中运行，而是直接在服务器上执行。
我认为，RSC 的设计初衷是将后端“组件化”，即相当于 SPA React 在前端所做的后端工作。从理论上讲，它们可以在很大程度上消除对 REST 和 GraphQL 等东西的需求，从而使服务器和客户端之间的集成更加紧密，因为一个组件可以穿越整个堆栈。– Reddit上的ExternalBison54
由于 RSC 直接在服务器上执行，它们可以高效地访问数据库和API等后端资源，而无需额外的数据获取层。
但我们为什么需要 RSC 呢？
要回答这个问题，让我们倒退一下。
传统的 React 客户端渲染（CSR）
React 一直是一个客户端 UI 库。
React 背后的核心理念是将整个设计划分为更小的、独立的单元，我们称之为组件。这些组件可以管理自己的私有数据（状态）并相互传递数据（道具）。
将这些组件视为 JavaScript 函数，可以在用户的浏览器中下载和运行。当有人访问您的应用时，他们的浏览器会下载所有组件代码，然后 React 会介入并呈现所有内容：
- 浏览器下载 HTML、JavaScript、CSS 和其他资产。
- React 会分析 HTML，为用户交互设置事件监听器，并检索任何所需的数据。
- 网站就在你眼前变成了一个功能齐全的 React 应用程序，一切都由浏览器和计算机完成。
虽然这个过程很有效，但也有一些缺点：
- 加载时间慢： 加载时间可能会很慢，尤其是对于有大量组件的复杂应用程序，因为现在用户必须先等待下载所有组件。
- 不利于搜索引擎优化（SEO）： 最初的 HTML 通常很简陋，只够下载 JavaScript，然后再渲染其余代码。这使得搜索引擎很难理解页面的内容。
- 应用程序越大，速度越慢： JavaScript 的客户端处理会造成资源紧张，导致用户体验不佳，尤其是在添加更多功能时。
下一个迭代：服务器端渲染（SSR）
为了解决客户端渲染带来的问题，React 社区采用了服务器端渲染（SSR）技术。
通过 SSR，服务器会先将代码渲染为 HTML，然后再发送给客户端。
然后，完整的渲染 HTML 将被传输到浏览器/移动设备上，供用户随时查看，应用程序无需像没有 SSR 那样在运行时编译。
以下是 SSR 的工作原理：
- 服务器为每个请求渲染初始 HTML。
- 客户端会收到一个完整的 HTML 结构，从而加快初始页面的加载速度。
- 然后，客户端下载 React 和您的应用程序代码，这个过程称为”hydration”，它使页面具有交互性。
服务器上呈现的 HTML 结构还没有任何功能。
React 会添加事件侦听器、设置内部状态管理，并在 HTML 下载到设备后添加其他功能。这种为页面添加 “生命 ”的过程被称为 “水合”。
SSR 为何如此有效？
- 更快的初始加载时间：用户几乎可以立即看到内容，因为浏览器接收到的是完整的 HTML，省去了 JavaScript 加载和执行所需的时间。
- 改进搜索引擎优化：搜索引擎可以轻松抓取和索引服务器渲染的 HTML。这种直接访问可为您的应用程序带来更好的搜索引擎优化效果。
- 提高较慢设备的性能：SSR 减轻了用户设备的负担。服务器承担了这些工作，即使在连接速度较慢的情况下，也能使您的应用程序更易于访问且性能更佳。
不过，SSR 也带来了一些额外的问题，需要一个更好的解决方案：
- 缓慢的交互时间（TTI）：服务器端渲染和水合会延迟用户查看应用程序并与之交互的时间 ，直到整个过程完成。
- 服务器负载：服务器需要做更多的工作，进一步减慢了复杂应用的响应时间，尤其是在有许多用户同时使用的情况下。
- 设置复杂性：设置和维护可能更加复杂，尤其是大型应用程序。
最后，React 服务器组件
2020 年 12 月，React 团队推出了 “Zero-Bundle-Size React Server Components” 或 RSC。
这不仅改变了我们构建 React 应用程序的思路，也改变了 React 应用程序的幕后工作方式。RSC 解决了我们在使用 CSR 和 SSR 时遇到的许多问题。
有了 RSC，React 变成了一个完全的服务器端框架和一个完全的客户端框架，这是我们以前从未有过的。这使得服务器和客户端代码之间的集成比以前更加紧密。-ExternalBison54 在 Reddit 上
现在让我们来看看 RSC 带来的好处：
1. 零捆绑大小
RSC 完全在服务器上呈现，无需向客户端发送 JavaScript 代码。这将带来
- 大大缩小了 JavaScript 代码包的大小。
- 页面加载速度更快，尤其是在速度较慢的网络上。
- 在性能较弱的设备上提高性能。
与 SSR 不同的是，RSC 将整个 React 组件树发送到客户端进行水合，而服务器只保留服务器代码。这将大大缩小我们谈到的客户端捆绑包，使您的应用程序更轻便、反应更灵敏。
2. 直接后台访问
RSC 可以直接与数据库和文件系统交互，而无需 API 层。
正如您在下面的代码中看到的，courses 变量直接从数据库中获取，用户界面从 courses.map 中打印出 course.id 和 course.name 列表：
async function CourseList() {
const db = await connectToDatabase();
const courses = await db.query('SELECT * FROM courses');
return (
<ul>
{courses.map(course => (
<li key={course.id}>{course.name}</li>
))}
</ul>
);
}
这与传统的 SSR 相比更为简单，因为传统的 SSR 需要设置单独的 API 路由来获取单个数据。
3. 自动代码分割
有了 RSC，您还可以获得更细粒度的代码拆分和更好的代码组织。
React 会将仅用于服务器的代码保留在服务器上，并确保这些代码永远不会被发送到客户端。客户端组件会被自动识别并发送到客户端进行水合。
由于客户端现在收到的正是一个功能完善的应用程序所需的内容，因此整个捆绑变得非常优化。
另一方面，SSR 需要仔细地手动拆分代码，以优化每个附加页面的性能。
4. 减少瀑布效应和流式渲染
React 服务器组件结合了流式渲染和并行数据获取。这种强大的组合大大减少了传统服务器端渲染中经常出现的“瀑布效应”。
瀑布效应
瀑布效应 “会降低网络开发速度。从根本上说，它迫使各种操作相互跟进，就像瀑布流过一系列岩石一样。
每一步都必须等待前一步完成。这种“等待”在数据获取中尤为明显。一个应用程序接口调用必须在下一个调用开始前完成，从而导致页面加载时间变慢。
流式渲染
流式渲染提供了一种解决方案。服务器无需等待整个页面在服务器上渲染完成，而是可以在用户界面准备就绪后立即将其发送到客户端。
React 服务器组件能更流畅地呈现和获取数据。它创建了多个并行工作的服务器组件，避免了瀑布效应。
一旦用户界面的任何部分准备就绪，服务器就会开始向客户端发送 HTML。
因此，与服务器端渲染相比，RSC
- 允许每个组件独立并行地获取数据。
- 一旦某个组件的数据准备就绪，服务器就可以立即对其进行流式处理，而无需等待其他组件跟上。
- 用户可以看到内容一个接一个地加载，从而增强他们对性能的感知。
5. 与客户端组件顺畅交互
现在，使用 RSC 并不意味着必须跳过客户端组件。
这两种组件可以共存，并帮助您创建出色的整体应用程序体验。
想一想电子商务应用程序。使用 SSR 时，整个应用程序需要在服务器端呈现。
而在 RSC 中，您可以选择哪些组件在服务器端呈现，哪些组件在客户端呈现。
例如，您可以使用服务器组件获取产品数据并呈现初始产品列表页面。
然后，客户端组件可以处理用户交互，如向购物车添加物品或管理产品评论。
您是否应该在路线图中加入 RSC 实现？
我们的结论？RSC 为 React 开发增添了很多价值。
它们解决了 SSR 和 CSR 方法中一些最紧迫的问题：性能、数据获取和开发人员体验。对于刚刚开始编码的开发人员来说，这让他们的生活变得更加轻松。
现在，您是否应该将 RSC 实现添加到您的路线图中？我们不得不说–视情况而定。
您的应用程序可能在没有 RSC 的情况下运行得很好。在这种情况下，添加另一层抽象层可能不会有太大作用。但是，如果您计划进行扩展，并认为 RSC 可以改善应用程序的用户体验，那么可以尝试进行一些小的改动，然后再进行扩展。
评论留言