原文：https://blog.axlight.com/posts/thoughts-on-what-rsc-means-for-spas/
作者：Daishi Kato
译者：ChatGPT 4 Turbo
引言
RSC 代表 React 服务器组件，但在这篇文章中，我将使用 RSC 来指代一个包含两个关键方面的更广泛的架构：
- 核心功能，即序列化和反序列化 React 组件及其他值的能力，
- 基于核心功能的最佳实践，我认为这个实践还有待探索。
SPA 或单页应用程序通常可以作为静态文件部署。尽管可能存在一个单独的服务器，但它通常不提供 SPA 本身。在这个上下文中，一个 SPA 可以有多个页面，但我们不纠结于精确的定义。
现在，正如名称所示，RSC 通常需要一个运行时服务器，且有了服务器会更加强大。但是，常说我们可以在没有服务器的情况下使用 RSC。
在这篇文章中，我想分享我对这个话题的一些随机想法。
为了集中讨论，我想排除 SSR（服务器端渲染）的范围。SSR 增加了在运行时服务器或构建时生成 HTML 的能力，无论如何它只是一项额外的有价值的功能。
RSC 如何立即为 SPA 带来好处？
即使没有运行时服务器，RSC 也为 SPA 提供了特定的优势。
如果我们没有运行时服务器，SPAs 似乎不会从 RSC 获得任何好处。然而，如果我们想减少 JS 包的大小，RSC 的序列化能力对 SPA 是有益的。如果组件树的某些部分是相对静态的，我们可以在构建时渲染组件并序列化它们。
RSC 负载是文本，可以作为静态文件提供。我们不需要发送 JS 代码来生成 RSC 负载。例如，一个 markdown 渲染器可以在构建时运行，如果我们不需要在客户端上渲染 markdown，我们就不需要在 JS 包中包含 markdown 渲染器。
RSC 负载的静态文件不需要最初就加载。SPA 可以根据需求获取它们，就像我们对 JS 包进行延迟加载一样。因此，我们基本上可以将一些客户端的工作转移到构建过程中。
在这种情况下，SPA 并不一定意味着以客户端为先。组件树应该以服务器为先，然后我们添加客户端组件。即使一个应用主要是由客户端组件构建的，我们仍然会有一些作为服务器组件的服务器组件，因为服务器和客户端组件可以在组件树中混合使用。
在我看来，一个缺点是思维的转变。现在，我们需要思考什么应该是服务器组件，什么应该是客户端组件。在纯粹的 SPA 中，我们不需要担心这个问题。所以，这是一种权衡。
如果我们有一个为 SPA 提供的 API 服务器，RSC 能做些什么？
如果我们有一个带有 SPA 的 API 服务器，我们可以使用 RSC。通常，我们会使用 JSON 作为 API 响应，但这可以被 RSC 负载替换。
使用 RSC 负载而不是纯 JSON 的好处包括：
- 我们可以发送已渲染的组件以及数据：再次强调，这避免了发送 JS 包来渲染组件。
- 我们可以流式传输数据：数据可以随着时间分块发送，允许用户看到它的到来。
- 我们不需要定义数据格式。RSC 负载就是在客户端可渲染的。
所以，基本上，它只是另一种线路协议。但是，这是为 React 准备的。我们通常使用 "use server" 指令，它允许与服务器的无缝集成，并有助于类型检查。
还有别的吗？
路由库在整合 RSC 能力方面将发挥重要作用。它们提供面向用户的 API 并隐藏了 RSC 的一些复杂性。它不必一定是路由器。也可以有另一个库来隐藏 RSC 的复杂性。只是目前看来，路由器似乎是最常见的库。
结语
这些只是我对 RSC 如何对 SPA 有益的初步思考。还有更多内容需要发掘，或许我应该用一些实际例子重新审视这个话题。Waku 可以用来创建使用 RSC 的静态站点示例。如果你对这在实践中是如何工作的感到好奇，我鼓励你尝试一下。