React 服务器组件：演变

简介

大约十年前，当我开始软件开发之路时，我只编写了 HTML、CSS、JavaScript 和一些 Python 2 脚本；在那段时间，我们仅依赖 PHP 和 SQL 进行服务器端客户端-服务器通信。之后，下一个层次是神奇的词“反应”，就像对状态或效果的变化做出反应。这是我的理解，没有深入探讨这个问题，有传言说是 Facebook 工程师制作的；这是我们用来编码前端部分的方式的重磅炸弹。

随着软件开发的发展和后端系统变得复杂，React Server Components (RSC) 认为我们的生态系统迫切需要发展。这让我想起了大量 JavaScript 捆绑包和“加载”旋转器无处不在的日子。让我们探索 RSC 如何改变游戏规则。

性能革命

RSC 带来的主要转变不仅是技术上的，而且是哲学上的。 RSC 不需要将整个组件树发送到客户端，而是让我们在服务器上渲染组件，同时保持我们喜欢的 React 交互性。我曾经将仪表板应用程序迁移到 RSC，这非常简单，没有什么特别的，而且仪表板应用程序的大小下降了 60%，效果明显。

这是我最近遇到的一个现实世界的例子：

 // Before: Client Component
 import { ComplexDataGrid } from 'heavy-grid-library';
import { format } from 'date-fns';

export default function Dashboard() {
  const [data, setData] = useState([]);

  useEffect(() => {
    fetchDashboardData().then(setData);
  }, []);

  return <ComplexDataGrid data={data} />;
}

在这种传统的客户端方法中，发生了几件事：

• 我们正在导入一个与我们的客户端 JavaScript 捆绑在一起的重型数据网格库。
• 我们使用 useState 在浏览器中本地管理我们的数据。
• 我们在组件安装后使用 useEffect 获取数据。
• 在获取数据时用户会看到加载状态。
• 所有数据处理都在浏览器中进行，可能会降低用户设备的速度。

现在，让我们看看 RSC 版本：

import { sql } from '@vercel/postgres';
import { DataGrid } from './DataGrid';

export default async function Dashboard() {
  const data = await sql`SELECT * FROM dashboard_metrics`;

  return <DataGrid data={data} />;
}

• 该组件默认是异步的 - 不需要 useEffect 或 useState。
• 通过服务器端查询直接访问数据库。
• 无需客户端数据获取代码。
• 初始数据需要零加载状态。
• 数据处理发生在强大的服务器上，而不是用户设备上。
• 导入的DataGrid组件可以更轻量，因为它只需要处理显示，而不是数据获取。

转变是惊人的。不再有 useEffect，不再有客户端数据获取，最重要的是，不再有不必​​要的 JavaScript 传送到客户端。

现实世界的好处

影响不仅仅限于性能指标。在使用 RSC 时，我注意到数据库查询现在更靠近数据源（在上面的示例中不是最佳编码实践），组件更简单、更集中，身份验证和授权模式变得更简单，并且 SEO改进几乎是免费的，这在 React 世界中是从未发生过的。

然而，最显着的优势是开发者体验。编写可以直接访问数据库的组件（安全！）感觉就像一种超能力。这就像两全其美：React 基于组件的架构，以及 Next.js 最先进的服务器端渲染的性能优势

权衡

说实话：RSC 并不完美。心智模型需要时间来掌握，尤其是理解客户端/服务器边界；对我来说，这是一种黑匣子中的复杂操作。我将遵循之前的迁移示例，我们遇到了一些与 RSC 不兼容的第三方库的障碍。解决方案是什么？混合方法：

 // Before: Client Component
 import { ComplexDataGrid } from 'heavy-grid-library';
import { format } from 'date-fns';

export default function Dashboard() {
  const [data, setData] = useState([]);

  useEffect(() => {
    fetchDashboardData().then(setData);
  }, []);

  return <ComplexDataGrid data={data} />;
}

让我们来分解一下这种混合方法中发生的情况：

• use client 指令显式地将 SearchFilter 标记为客户端组件。
• SearchFilter 处理只能在客户端上发生的用户交互（onChange 事件）。
• ProductList 仍然是一个服务器组件，在服务器端获取数据。
• 组件组合允许我们在适当的情况下混合服务器和客户端渲染。
• 只有交互部分（SearchFilter）将 JavaScript 传送到客户端。
• 数据密集的部分（包含产品的 ProductGrid）在服务器上呈现。

结论（未来是服务器优先）

RSC 代表的不仅仅是一个新功能 - 它是我们构建 React 应用程序时所传达的范例。将昂贵的计算和数据获取转移到服务器，同时维护 React 的组件模型的能力是革命性的。

对于构建数据量大的应用程序的团队来说，RSC 提供了一条在不牺牲开发人员体验的情况下获得更好性能的途径。随着环境的成熟和更多库与 RSC 兼容，我预计这种模式将成为我们构建 React 应用程序的默认方式。

分享您的经验

您开始在项目中使用 React Server 组件了吗？我很乐意在下面的评论中听到您的意见、挑战和胜利。
如果本文帮助您更好地了解 RSC，请点赞，并且不要忘记关注我以更深入地了解现代系统。

关于作者

Ivan Duarte 是一位拥有自由职业经验的后端开发人员。他对网络开发和人工智能充满热情，并喜欢通过教程和文章分享他们的知识。在 X、Github 和 LinkedIn 上关注我，获取更多见解和更新。

？ 订阅我们的时事通讯

直接在收件箱中阅读来自 ByteUp 的文章。

订阅时事通讯，不要错过。

？ 立即订阅 ?

以上是React 服务器组件：演变的详细内容。更多信息请关注PHP中文网其他相关文章！