1 篇博文含有标签「react」

理解 React 服务器组件

2023年11月7日 · 阅读需 40 分钟

简介

亲爱的,React 诞生十年了,这让我感到惊奇和欣慰。在这十年里,React 经历了几次重大的升级迭代。React 团队一直在尝试新的解决方案。比如,他们最近发布了 React 服务器组件,这是一次巨大的变革。服务器组件可以完全运行在服务器端。

网上对这一新特性有很多困惑和疑问。我尝试了服务器组件,并解答了许多自己的疑问。我对它越来越激动了。它真的很酷!

我今天的目标是帮助大家消除关于 React 服务器组件的疑惑,回答你们可能有的问题。

提示

本教程主要针对已经在使用 React 的开发者,特别是那些对 React 服务器组件感兴趣的人。你不需要是 React 专家,但如果你才刚刚开始学习 React,可能会觉得比较困惑。

关于服务端渲染的简单介绍

为了理解 React 服务端组件,首先需要了解服务端渲染(SSR)的工作原理。如果你已经熟悉 SSR,可以直接跳到下一节!

当我 2015 年刚开始使用 React 时,大多数 React 应用采用“客户端渲染”策略。用户会收到一个像这样的 HTML 文件:

<!DOCTYPE html>
<html>
    <body>
        <div id="root"></div>
        <script src="/static/js/bundle.js"></script>
    </body>
</html>

这个 bundle.js 脚本包含了我们需要的所有代码,包括 React、第三方依赖和我们编写的代码。

加载并解析 JS 后,React 会立即开始工作,在空的 <div id="root"> 中生成整个应用的 DOM 节点。

这个方法的问题是需要时间来完成所有工作。而在此期间,用户会面对一个空白页面。随着我们不断添加新特性,这个问题会越来越严重,因为 JS bundle 会变得越来越大,加载和解析的时间也越长。

服务端渲染就是为了改善这一体验而设计的。服务器不再发送空白 HTML ,而是渲染我们的应用生成实际的 HTML。这样用户可以立即看到完整的页面。

生成的 HTML 仍会包含 <script> 标签,因为我们仍需要 React 在浏览器端运行,来处理交互。但是我们会以稍微不同的方式配置浏览器中的 React:它不再从头开始生成所有 DOM 节点,而是采用已存在的 HTML。这个过程称为水化。

React 核心团队成员 Dan Abramov 是这样解释水化的:

水化就像用互动和事件处理程序的“水”浇灌“干燥”的 HTML。

一旦 JS bundle 下载完成,React 会快速遍历整个应用,构建一个 UI 的虚拟示意图,并将其“套上”真实 DOM,绑定事件处理函数,触发效果等等。

总之,这就是 SSR 的工作原理。服务器生成初始 HTML,这样用户不再需要面对空白页等待 JS 下载和解析。客户端 React 接手服务端 React 的工作,采用 DOM 并添加交互。

总结

当我们谈论服务端渲染时,通常想象的流程如下:

用户访问 myWebsite.com。
Node.js 服务器接收请求,并立即渲染 React 应用,生成 HTML。
刚生成的 HTML 发送给客户端。

这是实现服务端渲染的一种方式,但并非唯一方式。另一种选择是在构建应用时生成 HTML。

通常,React 应用需要被编译,将 JSX 转换为普通 JavaScript,并打包所有模块。如果在同一过程中,我们为所有不同的路由“预渲染”了所有 HTML,岂不很好?

这就是通常所说的静态网站生成(SSG)。它是服务端渲染的一个子变种。

在我看来,“服务端渲染”是一个总括术语,包括几种不同的渲染策略。它们有一个共同点:初始渲染发生在像Node.js 这样的服务器运行时,使用 ReactDOMServer API。渲染何时发生并不重要,无论是按需还是在编译时都算是服务端渲染。

客户端与服务端的往返

让我们来讨论 React 中的数据获取。通常,我们会有两个相互通过网络进行通信的应用:客户端 React 应用服务端 REST API 使用像 React Query、SWR 或 Apollo 这样的库,客户端会发起网络请求到后端,后端再从数据库获取数据并通过网络发回。

我们可以用一个图来可视化这个流程:

说明

本文包含几个“网络请求图”,目的是可视化不同渲染策略下,数据在客户端(浏览器)和服务端(后端 API)之间的传递。

底部的数字代表一个假想的时间单位,并不是分钟或秒。实际的数字会根据许多不同因素而大相径庭。 这些图旨在帮助你从高层次理解相关概念,并不是在模拟任何真实数据。

主要关注数据流动的 overall 方向和 client 与 server 之间的往返次数。具体的时间数值并不重要,仅用于说明的目的。

这个第一个图展示了使用客户端渲染(CSR)策略的流程。它从客户端收到一个 HTML 文件开始。这个文件没有任何内容,只包含一个或多个 <script>标签。

一旦 JS 下载并解析后,我们的 React 应用会启动,生成一堆 DOM 节点并填充 UI。但一开始,我们还没有任何实际的数据,所以只能渲染布局(头部、底部、总体布局)和加载状态。

你可能经常见过这种模式。例如,Uber Eats 在获取需要的数据渲染实际餐厅之前,会先渲染布局:

用户会看到这个加载状态,直到网络请求完成,React 用真实内容重新渲染为止。

让我们看另一种架构方式。 这个图保持了相同的数据获取模式,但使用了服务端渲染而不是客户端渲染:

在这个新的流程中,我们在服务器上执行首次渲染。这意味着用户收到的 HTML 文件不再是完全空白的。

这是一个改进 - 相比空白页,shell 体验更好 - 但从整体来看,它并没有带来非常明显的提升。用户访问我们的应用不是为了看加载界面,而是为了查看内容(餐厅、酒店、搜索结果、消息等等)。

为了真正理解用户体验上的差异,我们在图中添加一些网页性能指标。在这两种流程中切换,并留意指标的变化:

这些标志代表了一些常用的网页性能指标。具体如下:

首次绘制 - 用户不再盯着空白屏幕。总体布局已经渲染出来,但内容还缺失。这有时也称为 FCP(首次内容绘制)。
页面可交互 - React 已下载,应用已经渲染/水化。可交互元素现在可以完全响应。这有时也称为 TTI(可交互时间)。
内容绘制 - 页面现在包含用户关心的内容。我们从数据库拉取数据并在 UI 中渲染出来。这有时也称为 LCP(最大内容绘制)。

通过在服务器上进行初始渲染,我们可以更快地绘制那个初始“shell”。这可以使加载体验感觉更快,因为它提供了进度的感觉,似乎东西在发生。

在某些情况下,这确实会是一个明显的改进。例如,用户可能只是等待头部加载以便点击一个导航链接。

但这种流程感觉有点傻,不是吗? 当我看SSR图时,我不禁注意到请求是从服务器上开始的。与需要第二次网络往返请求不同,为什么我们不在那个初始请求期间进行数据库工作呢?

换句话说,为什么不这样做呢?

通过在初始请求中获取数据,我们可以避免客户端需要进行第二次请求。这不仅改善了性能,还简化了客户端的逻辑。

总体来说,能在一个请求中完成服务端渲染和数据获取是更好的方案。这正是React服务端组件希望解决的问题。

与其客户端与服务端来回跳转,不如我们在初始请求中进行数据库查询,直接将填充了数据的 UI 发送给用户。

但问题是,我们要如何具体实现呢?

为了让这种方式可行,我们需要能够给 React 一段仅在服务端运行的代码,用来进行数据库查询。但在 React 中一直没有这样的选项......即使使用服务端渲染,我们的所有组件也会在服务端和客户端都渲染。

为解决这个问题,生态系统提出了许多方案。一些元框架,比如 Next.js 和 Gatsby 创造了自己的方式在服务端执行代码。

例如,使用 Next.js(传统的 “页面” 路由)看起来像这样:

import db from 'imaginary-db';
// This code only runs on the server:
export async function getServerSideProps() {
  const link = db.connect('localhost', 'root', 'passw0rd');
  const data = await db.query(link, 'SELECT * FROM products');
  return {
    props: { data },
  };
}
// This code runs on the server + on the client
export default function Homepage({ data }) {
  return (
    <>
      <h1>Trending Products</h1>
      {data.map((item) => (
        <article key={item.id}>
          <h2>{item.title}</h2>
          <p>{item.description}</p>
        </article>
      ))}
    </>
  );
}

让我们分解一下: 当服务端收到请求时,getServerSideProps 函数会被调用。它返回一个 props 对象。那些 props 会注入组件,组件首先在服务端渲染,然后在客户端水化。

巧妙之处在于,getServerSideProps 不会在客户端重新运行。事实上,这个函数甚至不会被打包到我们的 JavaScript 中!

这种方法非常前卫。老实说,它非常棒。但也存在一些缺点:

这种策略只适用于路由层面的组件,也就是组件树的顶层。我们无法在任意组件中使用。
每个元框架都提出了自己的解决方案。Next.js 有一套方式,Gatsby 有另一套,Remix 也不同。还没有标准化。
我们的所有 React 组件总是会在客户端水化,即使没有必要。

多年来,React 团队一直在悄悄研究这个问题,设法提出官方的解决方案。他们的解决方案被称为 React 服务端组件。

React 服务器组件简介

从高层次来看,React 服务端组件 是一种全新的范例。在这种新方案中,我们可以创建只在服务端运行的组件。这使我们可以在 React 组件内直接编写数据库查询等操作!

这样就无需像以前那样在服务端和客户端编写重复的渲染逻辑。我们可以用同一组件同时处理服务端渲染和数据获取。

React 服务端组件为构建真正的同构 React 应用提供了基础。这是 React 在可扩展性和性能上的一次突破。

这是“服务器组件”的一个简单示例：

import db from 'imaginary-db';
async function Homepage() {
  const link = db.connect('localhost', 'root', 'passw0rd');
  const data = await db.query(link, 'SELECT * FROM products');
  return (
    <>
      <h1>Trending Products</h1>
      {data.map((item) => (
        <article key={item.id}>
          <h2>{item.title}</h2>
          <p>{item.description}</p>
        </article>
      ))}
    </>
  );
}
export default Homepage;

作为使用React多年的开发者,起初看到这种代码我觉得非常惊讶。 😅

我的直觉尖叫着:“等等!函数组件不可以是异步的!我们也不允许在渲染中直接有副作用!”

需要理解的关键是: 服务端组件永远不会重新渲染。它们在服务器上运行一次来生成UI。渲染后的值被发送到客户端并固定住。从 React 的角度看,这个输出是不变的,永远不会改变。*

这意味着 React 的大部分 API 与服务端组件不兼容。例如,我们不能使用 state,因为 state 可以改变,但服务端组件无法重新渲染。我们也不能使用 effects,因为 effects 只会在渲染之后运行,在客户端上,而服务端组件永远不会到达客户端。

这也意味着我们在规则上有更多灵活性。例如,在传统 React 中,我们需要把副作用放进 useEffect 回调或事件处理函数中,以防它们在每次渲染时重复执行。但是如果组件只运行一次,我们就不需要担心这个问题!

服务端组件本身非常简单,但“React 服务端组件”范式要复杂得多。这是因为我们仍然有通常的组件,它们的组合方式可能会让人困惑。

在这种新范式中,我们熟悉的“传统” React 组件称为客户端组件。坦白说,我不太喜欢这个名称。😅

“客户端组件”这个名称意味着这些组件只会在客户端渲染,但实际上不是这样。客户端组件会在客户端和服务端都渲染

我知道所有的这些术语都很容易让人困惑,所以我来概括一下:

React 服务端组件是这种新范式的名字。
在这种新范式中,我们熟知和喜爱的“标准” React 组件被重新命名为客户端组件。这是旧事物的新名字。
这个新范式引入了一种新的组件类型,服务端组件。这些新组件仅在服务端渲染。它们的代码不会被打包到 JS 中,也不会水化或重新渲染。

React 服务端组件 vs 服务端渲染

让我们澄清另一个常见的困惑:React 服务端组件不是服务端渲染的替代品。你不应该认为 React 服务端组件是“SSR 2.0”。

相反,我喜欢把它看作是两个可以完美嵌合的拼图片段,两种互补的风味。

我们仍然依赖服务端渲染来生成初始 HTML。React 服务端组件在此基础上,允许我们从客户端 JavaScript 包中省略某些组件,确保它们只在服务器上运行。

事实上,即使不使用服务端渲染,也可以使用 React 服务端组件,尽管在实践中,把两者结合使用可以获得更好的效果。如果你想看例子,React 团队已经建立了一个不使用 SSR 的最小化 RSC 演示。

兼容环境

通常情况下，当推出新的React功能时，我们可以通过将React依赖项升级到最新版本来在现有项目中开始使用它。快速运行npm install react@latest命令，就可以开始使用了。

不幸的是，React服务端组件并不像这样工作。

据我了解，React服务端组件需要与React之外的许多其他内容进行紧密集成，例如打包工具、服务器和路由器。

截至我撰写此文时，开始使用React服务端组件的唯一方法是使用Next.js 13.4+，并使用其全新重新架构的“App Router”。

希望在将来，更多基于React的框架将开始整合React服务端组件。一个核心的React功能只在一个特定的工具中可用，这感觉有些尴尬！React文档中有一个“Bleeding-edge frameworks”（最前沿的框架）部分，列出了支持React服务端组件的框架；我计划不时查看该页面，以了解是否有新的选择可用。

指定客户端组件

在这个新的“React 服务器组件”范例中，默认情况下所有组件都被假定为服务器组件。我们必须“选择加入”客户端组件。

我们通过指定一个全新的指令来做到这一点：

'use client';

import React from 'react';

function Counter() {
  const [count, setCount] = React.useState(0);
  return (
    <button onClick={() => setCount(count + 1)}>
      Current value: {count}
    </button>
  );
}
export default Counter;

在顶部的独立字符串'use client'是我们向React发出的信号，表明该文件中的组件是客户端组件，它们应该包含在我们的JS捆绑包中，以便在客户端上重新渲染。

这可能看起来是一种非常奇怪的指定组件类型的方式，但在这种情况下有一个先例：JavaScript中的“use strict”指令，它选择进入“严格模式”。

在我们的服务器组件中，我们不需要指定'use server'指令；在React服务端组件范例中，默认情况下将组件视为服务器组件。实际上，'use server'用于服务器操作，这是一个完全不同的功能，超出了本博文的范围。

应该使用客户端组件还是服务端组件?

你可能会猜测:我应该如何决定一个组件应该是服务端组件还是客户端组件?

总的来说,如果一个组件可以是服务端组件,那它就应该是服务端组件。服务端组件往往更简单,更容易推理。性能也更好:因为服务端组件不会运行在客户端,它们的代码不会被打包到 JavaScript 中。React 服务端组件范式的好处之一是它有可能改善可交互时间(TTI)指标。

也就是说,我们也不应该把使客户端组件尽可能少作为目标!我们不应该试图优化最小数量的客户端组件。值得记住,在此之前,每一个 React 应用中的每个组件都是客户端组件。

当你开始使用 React 服务端组件时,你会发现这很直观。一些组件需要在客户端运行,因为它们使用 state 或 effects。你可以在这些组件上加一个 'use client' 指令。否则,它们可以留作服务端组件。

边界

当我开始熟悉React服务端组件时，我最初遇到的一个问题是：当props发生变化时会发生什么？

例如，假设我们有一个如下所示的服务器组件：

function HitCounter({ hits }) {
  return (
    <div>
      Number of hits: {hits}
    </div>
  );
}

假设在初始服务器端渲染中，点击次数等于 0。然后，该组件将生成以下标记：

<div>
  Number of hits: 0
</div> 

但是,如果 hits 的值改变了呢?假设它是一个 state 变量,从 0 变成了 1。HitCounter 需要重新渲染,但是它不能重新渲染,因为它是一个服务端组件!

关键是,服务端组件单独使用并不合理。我们需要拉远视角,从更全局的角度考虑我们的应用结构。

假设我们有如下组件树:

如果所有组件都是服务端组件,那么一切都说得通。props 永远不会改变,因为没有组件会重新渲染。

但是假设 Article 组件拥有 hits 状态变量。为了使用状态,我们需要将其转换为客户端组件:

你看到问题了吗?当 Article 重新渲染时,它拥有的组件也会重新渲染,包括 HitCounter 和 Discussion。但是如果它们是服务端组件,它们就不能重新渲染。

为了防止这种不可能的情况,React 团队添加了一个规则:客户端组件只能导入其他客户端组件。这个 'use client' 指令意味着这些 HitCounter 和 Discussion 实例需要变成客户端组件。

我在学习 React 服务端组件时的最大“灵光一闪”时刻之一,是意识到这种新范式完全是关于创建客户端边界。在实践中,会发生这样的情况:

当我们在 Article 组件中添加 'use client' 指令时,我们创建了一个“客户端边界”。这个边界中的所有组件都会隐式地转换为客户端组件。即使像 HitCounter 这样的组件没有 'use client' 指令,在这种特定情况下它们也会在客户端上水化/渲染。*

这意味着我们不需要在每个需要在客户端运行的文件中添加 'use client'。在实践中,只有在创建新的客户端边界时才需要添加它。

解决方法

当我第一次了解到客户端组件不能渲染服务端组件时,我觉得这很具有限制性。如果我需要在应用的较高层使用状态怎么办?这是不是意味着所有东西都需要变成客户端组件??

结果表明,在许多情况下,我们可以通过重构应用程序以改变所有者来绕过这个限制。

这是一件很难解释的事情，所以让我们举个例子：

'use client';

import { DARK_COLORS, LIGHT_COLORS } from '@/constants.js';
import Header from './Header';
import MainContent from './MainContent';

function Homepage() {
  const [colorTheme, setColorTheme] = React.useState('light');
  const colorVariables = colorTheme === 'light'
    ? LIGHT_COLORS
    : DARK_COLORS;
  return (
    <body style={colorVariables}>
      <Header />
      <MainContent />
    </body>
  );
}

在这个设置中,我们需要使用 React 状态允许用户在深色模式和浅色模式之间切换。这需要在应用树的较高层次发生,以便我们可以将 CSS 变量应用于 <body> 标签。

为了使用状态,我们需要将 Homepage 转换为客户端组件。由于这是应用的顶层,这意味着所有其他组件 —— Header 和 MainContent —— 也会隐式地成为客户端组件。

要解决这个问题,我们可以将颜色管理逻辑提取到它自己的组件和文件中:

// /components/ColorProvider.js
'use client';

import { DARK_COLORS, LIGHT_COLORS } from '@/constants.js';

function ColorProvider({ children }) {
  const [colorTheme, setColorTheme] = React.useState('light');
  const colorVariables = colorTheme === 'light'
    ? LIGHT_COLORS
    : DARK_COLORS;
  return (
    <body style={colorVariables}>
      {children}
    </body>
  );
}

回到Homepage，我们像这样使用这个新组件:

// /components/Homepage.js
import Header from './Header';
import MainContent from './MainContent';
import ColorProvider from './ColorProvider';

function Homepage() {
  return (
    <ColorProvider>
      <Header />
      <MainContent />
    </ColorProvider>
  );
}

我们可以从 Homepage 中删除 'use client' 指令,因为它不再使用 state 或其他客户端 React 特性。这意味着 Header 和 MainContent 不再会被隐式转换为客户端组件!

但是等一下。 ColorProvider,一个客户端组件,是 Header 和 MainContent 的父组件。不管怎样,它在树中的位置仍然更高,对吧?

但是就客户端边界而言,父子关系并不重要。导入和渲染 Header 和 MainContent 的是 Homepage。这意味着 Homepage 决定了这些组件的 props。

记住,我们要解决的问题是服务端组件不能重新渲染,因此不能给它们的任何 props 新的值。通过这个新的设置,决定 Header 和 MainContent props 的是 Homepage,而 Homepage 是一个服务端组件,所以没有问题。

这些概念很难理解。 即使有多年 React 经验,我还是觉得非常困惑😅。这需要相当多的练习来培养直觉。

更准确地说,'use client' 指令作用于文件/模块层面。在客户端组件文件中导入的任何模块也必须是客户端组件。当打包器打包我们的代码时,它会根据这些导入进行跟踪!

更改颜色主题？

在我上面的例子中,你可能已经注意到没有方法改变颜色主题。setColorTheme 从未被调用过。

我想尽可能保持最小化,所以省略了一些内容。完整的例子会使用 React 上下文使设置器函数对所有子孙组件可用。只要消费上下文的组件是一个客户端组件,一切都可以良好工作!

窥视底层

让我们从更底层来看。当我们使用服务端组件时,输出是什么样子的?到底生成了什么?服务端组件的输出是一段预渲染的静态 HTML。

让我们从一个超级简单的 React 应用程序开始：

function Homepage() {
  return (
    <p>
      Hello world!
    </p>
  );
}

在React Server Components范式中，默认情况下，所有组件都是服务器组件。由于我们没有明确将此组件标记为客户端组件（或在客户端边界内渲染它），它将仅在服务器上呈现。

当我们在浏览器中访问此应用程序时，我们将收到类似以下内容的HTML文档：

<!DOCTYPE html>
<html>
  <body>
    <p>Hello world!</p>

    <script src="/static/js/bundle.js"></script>
    <script>
      self.__next['$Homepage-1'] = {
        type: 'p',
        props: null,
        children: "Hello world!",
      };
    </script>
  </body>
</html>

作了一些修改

为了更容易理解,我对这里的内容作了一些调整。例如,在 RSC 中生成的真实 JS 使用字符串化的 JSON 数组,作为一种优化来减小这个 HTML 文档的大小。

我也去掉了 HTML 中所有非关键部分(如 <head>)。

我们看到 HTML 文档包含了 React 应用生成的 UI,“Hello world!”段落。这多亏了服务端渲染,与 React 服务端组件没有直接关系。

在下面,我们有一个 <script> 标签来加载 JS bundle。这个 bundle 包含依赖如 React,以及应用中使用的任何客户端组件。而由于我们的 Homepage 组件是一个服务端组件,该组件的代码不会被打包进来。

最后，我们有第二个 <script> 标签，其中包含一些内联 JS：

self.__next['$Homepage-1'] = {
  type: 'p',
  props: null,
  children: "Hello world!",
};

这是真正有趣的部分。本质上,我们在这里告诉 React “嘿,我知道你缺少 Homepage 组件代码,但别担心:这里是它渲染的结果”。

通常,当 React 在客户端水化时,它会快速渲染所有组件,构建应用的虚拟表示。它无法对服务端组件这样做,因为代码没有被打包。

因此,我们发送渲染后的值,也就是服务端生成的虚拟表示。当 React 在客户端加载时,它会重用这个描述而不是重新生成。

这就是上面的 ColorProvider 例子能够工作的原因。Header 和 MainContent 的输出通过 children prop 传递给 ColorProvider 组件。ColorProvider 可以随意重新渲染,但这个数据是静态的,被服务端锁定。

如果你想了解服务端组件的序列化和通过网络发送的真实表示,可以查看开发者 Alvar Lagerlöf 的 RSC Devtools。

备注

服务端组件不需要服务端

前文中我提到,服务端渲染是许多不同渲染策略的“总称”,包括:

静态:HTML 在构建应用时生成,在部署过程中。
动态:HTML 是“按需”生成的,在用户请求页面时。

React 服务端组件与这两种渲染策略兼容。当我们的服务端组件在 Node.js 运行时中渲染时,它们返回的 JavaScript 对象会被创建。这可以按需发生,也可以在构建时发生。

这意味着可以在没有服务端的情况下使用 React 服务端组件!我们可以生成一堆静态 HTML 文件,并把它们托管在任意地方。事实上,这就是 Next.js App Router 中的默认行为。除非我们确实需要按需发生,否则所有这些工作都提前在构建时完成。

备注

完全不需要 React 吗?

你可能会想:如果我们的应用中不包含任何客户端组件,那我们是否可以完全不需要下载 React?我们可以通过 React 服务端组件构建一个真正的无 JS 静态网站吗?

问题是,React 服务端组件目前仅在 Next.js 框架内可用,而该框架有大量代码需要在客户端运行,以管理路由等功能。

反直觉的是,这实际上往往能带来更好的用户体验;例如,Next 的路由器可以比典型的 <a>标签更快处理链接点击,因为它不需要加载一个全新的 HTML 文档。

一个结构良好的 Next.js 应用在 JS 下载期间也可以工作,但 JS 加载完成后会更快更好

建议

React 服务端组件是在 React 中运行只在服务端的代码的第一个“官方”方式。但是如我前面提到的,从更广泛的 React 生态来看,这并不是一个真正新的事物;自2016年起,我们就可以在 Next.js 中运行只在服务端的代码了!

最大的不同在于,我们以前没有在组件内运行只在服务端的代码的方式。

最明显的好处是性能。服务端组件不会被打包到我们的 JS 中,这减小了需要下载的 JavaScript 数量,也减少了需要水化的组件数量:

这对我来说可能是最不令人兴奋的一点。老实说,大多数 Next.js 应用在“可交互时间”方面已经够快了。

如果遵循语义化 HTML 的原则,你的应用大部分应该可以在 React 水化之前就可以工作。链接可以点击,表单可以提交,折叠面板可以展开收起(使用 <details> 和 <summary>)。对于大多数项目来说,React 水化需要几秒钟是可以接受的。

但我发现一件真正很酷的事: 我们不再需要在功能和包体积之间做出妥协!

例如,大多数技术博客都需要某种语法高亮库。在我的博客上,我使用 Prism。代码示例看起来像这样:

function exampleJavaScriptFunction(param) {
  return "Hello world!"
}

一个合适的语法高亮库,支持所有流行的编程语言,可能有几兆字节,远远超过 JS 包的体积限制。因此,我们不得不做出妥协,只保留对任务至关重要的语言和特性支持。

但是,如果我们在服务端组件中执行语法高亮,那么库的代码实际上不会被打包到 JS 中。这样,我们就不需要做任何妥协,可以使用所有的特性。

这就是 Bright 的设计理念,一个面向 React 服务端组件的现代语法高亮包。

这就是我对 React 服务端组件感到兴奋的原因。之前由于考虑包体积无法引入的特性,现在可以在服务端免费运行,没有增加包的大小,还能提升用户体验。

这不仅仅是关于性能和用户体验。在使用 RSC 一段时间后,我很欣赏服务端组件的简单优雅。我们不需要再担心依赖数组、过时闭包、记忆化或其他因“变化”而导致的复杂问题。

目前还处于非常早期阶段。React 服务端组件仅在几个月前才从测试版毕业!我真的很期待在未来几年看到社区如何发展,提出像 Bright 这样的创新解决方案,利用这种新范式。这对 React 开发者来说是一个激动人心的时刻!

完整图片

简介​

客户端与服务端的往返​

React 服务器组件简介​

兼容环境​

指定客户端组件​

边界​

解决方法​

窥视底层​

建议​

简介