React Server Components (RSC) 正在彻底改变前端架构。您可能听说过这个名字，但是您是否确切知道它与SSR（服务器端渲染）有何不同以及幕后进行了什么样的处理？ 在本文中，我们将深入探讨其技术机制并考虑其实际使用的示例。
与 SSR 的决定性区别
传统的SSR是一种在初始加载期间在服务器端生成HTML并将其返回给浏览器的技术。但随后浏览器必须加载 JavaScript 并重新运行（水合）该组件以使其具有交互性。换句话说，组件代码本身最终被下载到浏览器。
另一方面，RSC 是一个仅在服务器上运行且从不发送到浏览器的组件。 RSC经过服务器处理后，会被序列化为特殊的类似JSON的格式而不是HTML，然后发送到客户端。浏览器端只是接收这些数据并将其反映在 DOM 中。
捆绑包大小大幅减小
这种机制的最大好处是减少了发送到客户端的 JavaScript 包的大小。 例如，假设您想使用一个重型库（例如“marked”）将 markdown 转换为 HTML。如果您使用 RSC 实现此功能，则所有解析都在服务器上完成，因此不会将繁重的库代码下载到用户的浏览器。这是移动环境性能的革命性改进。
客户端边界设计是关键。
使用 RSC 时最麻烦的事情是设计服务器和客户端组件之间的边界。 由于 RSC 在服务器上运行，因此它不能具有事件处理程序，例如“onClick”或状态管理（“useState”）。只有需要它们的最终组件（按钮和输入表单）才应该成为客户端组件。
需要一种树形结构设计理念，其中“数据采集和繁重处理在树的上层（服务器）进行，只有需要用户操作的叶子部分作为客户端。”
实际使用示例
在实践中，RSC 在以下用例中表现最为出色：
- 博客和媒体文章展示： 与上面提到的Markdown转换一样，RSC在渲染静态内容方面是独一无二的。
- 直接数据库访问： 由于RSC 是服务器环境，因此您可以安全地将查询直接发送到数据库。由于可以省略一层API，因此可以节省开发工作量。
- 专注于 SEO 的登陆页面： 快速初始加载，无需额外的 JS，这会直接提高您的 Core Web Vitals 分数。
RSC 并不是要取代现有的 React，而是澄清客户端和服务器之间“角色分工”的新武器。正确理解这一机制并将其适当地融入到设计中将是未来前端开发的关键。