近日，React 发布了 2024 年开发计划，建议正在使用 React 或者对 React 感兴趣的同学都关注一下。

到 2024 年底，你可能再也不需要这些 API 了：
useMemo, useCallback, memo → React Compiler，React Compiler 不再是一个实验项目了，以后 useMemo, useCallback, memo 这些被所有人所诟病的 API 就都不需要了，理解上会简单的多。
forwardRef → ref is a prop
React.lazy → RSC, promise-as-child
useContext → use(Context)
throw promise → use(promise)

<Context.Provider> → <Context>

下面是详细内容：
React Compiler
React Compiler 已不再是一个研究项目：现在，该编译器已为 instagram.com 的生产环境提供了支持，我们正努力将该编译器在 Meta  的更多平台上运行，并准备发布第一个开源版本。

正如我们之前所讨论的，当状态发生变化时，React 有时会过多地重新渲染。自 React 推出之初，我们对此类情况的解决方案就是手动记忆化。在我们当前的 API 中，这意味着应用 useMemo、useCallback 和 memo API 来手动调整 React 在状态变化时重新渲染的程度。但手动记忆化是一种妥协。它使我们的代码变得混乱，容易出错，而且需要额外的工作来保持更新。

手动记忆化是一个合理的折衷方案，但我们并不满意。我们的愿景是，当状态发生变化时，React 可以自动重新渲染用户界面的正确部分，而不会影响 React 的核心心智模型。我们相信，React 的方法（用户界面是状态的一个简单函数，采用标准的 JavaScript 值和习语）是 React 能够让如此多的开发人员接受的关键原因。这也是我们投资构建 React 优化编译器的原因。

由于 JavaScript 的规则松散且具有动态特性，因此它是一门极具挑战性的优化语言。React 编译器通过对 JavaScript 规则和 "React 规则"进行建模，能够安全地编译代码。例如，React 组件必须是幂等的，即在输入相同的情况下返回相同的值，并且不能修改 props 或 state 的值。这些规则限制了开发人员的行为，有助于为编译器的优化开辟安全空间。

当然，我们也理解开发人员有时会稍稍违反规则，我们的目标是让 React 编译器在尽可能多的代码上都能正常工作。编译器会尝试检测代码是否没有严格遵守 React 的规则，并在安全的情况下编译代码，或者在不安全的情况下跳过编译。我们正在针对 Meta 庞大而多样的代码库进行测试，以帮助验证这种方法。

对于希望确保自己的代码遵循 React 规则的开发人员，我们建议启用严格模式并配置 React 的 ESLint 插件。这些工具可以帮助您捕捉 React 代码中的细微错误，从而提高当前应用的质量，并为即将推出的功能（如 React 编译器）做好未来应用的准备。我们还在编写 React 规则的综合文档，并对 ESLint 插件进行更新，以帮助团队理解和应用这些规则，从而创建更强大的应用程序。

要了解编译器的实际运行情况，可以查看我们去年秋天的演讲（https://www.youtube.com/watch?v=qOQClO3g8-Y）。当时，我们在 instagram.com 的一个页面上试用了 React 编译器，并获得了早期实验数据。从那时起，我们就在 instagram.com 上部署了编译器。我们还扩大了团队，以加速向 Meta 的其他页面和开源项目推广。我们对未来的发展充满信心，并将在未来几个月与大家分享更多。

Actions
我们之前分享过我们正在探索的解决方案，通过服务器操作将数据从客户端发送到服务器，这样您就可以执行数据库突变并实现表单。在开发 Server Actions 的过程中，我们扩展了这些 API，使其也能支持仅客户端应用程序中的数据处理。

我们将这种更广泛的功能集合简称为 "操作"。通过 Actions，您可以向 DOM 元素（如 <form/>）传递函数：

<form action={search}>
  <input name="query" />
  <button type="submit">Search</button>
</form>

Action 函数可以同步或异步运行。您可以使用标准 JavaScript 在客户端定义动作，也可以使用 'use server' 指令在服务器端定义动作。使用动作时，React 将为您管理数据提交的生命周期，并提供 useFormStatus 和 useFormState 等钩子来访问表单动作的当前状态和响应。

默认情况下，action 在 transition 里提交，这样在处理 action 时，可以保持当前页面的交互性。由于 action 支持异步函数，我们还添加了在 transition 中使用 async/await 的功能。这允许我们在 fetch 等异步请求启动时，显示 transition 的 isPending 状态的待定 UI，并在应用更新的整个过程中显示待定 UI。

除了 action 之外，我们还引入了一项名为 useOptimistic 的功能，用于管理积极状态更新。使用此钩子，我们可以应用临时更新，一旦最终状态提交，这些更新就会自动恢复。对于 action，假设提交成功，这允许我们乐观地设置客户端上数据的最终状态，并恢复为从服务器接收的数据的值。它使用常规 async/await 奏效，因此无论是我们在客户端上使用 fetch，还是来自服务器的 Sever Action，其工作原理都相同。

库作者可以使用 useTransition 在自己的组件中实现自定义的 action={fn} props。我们的目的是让库在设计其组件 API 时采用Actions 模式，从而为 React 开发人员提供一致的体验。例如，如果您的库提供了 <Calendar onSelect={eventHandler}> 组件，请考虑同时公开 <Calendar selectAction={action}> API。

虽然我们最初关注的是用于客户端-服务器数据传输的Server Actions，但我们的 React 理念是在所有平台和环境中提供相同的编程模型。在可能的情况下，如果我们在客户端引入一项功能，我们的目标是让它也能在服务器上运行，反之亦然。这种理念使我们能够创建一套单一的 API，无论您的应用程序在哪里运行都能正常工作，从而使以后升级到不同环境变得更加容易。

Actions 现已在 Canary 通道中提供，并将在 React 的下一个版本中发布。

New Features in React Canary
我们引入了 React Canaries 作为一个选项，以便在稳定的 semver 版本发布之前，在设计接近完成时尽快采用个别新的稳定功能。

Canaries 是我们对 React 开发方式的一种改变。以前，功能的研究和构建都是在 Meta 内部私下进行的，因此用户只能在发布到稳定版时才能看到最终的完善产品。有了 Canaries，我们将在社区的帮助下公开开发，最终完成我们在 React Labs 博客系列中分享的功能。这意味着您可以在新功能定稿时而不是完成后更快地了解它们。

React Server Components、Asset Loading、Document Metadata 和 Actions 都已发布到 React Canary 中，我们还在 react.dev 上添加了这些功能的文档：

Directives："use client"和 "use server"是专为全栈 React 框架设计的捆绑程序功能。它们标志着两种环境之间的 "分割点"："use client" 指示捆绑程序生成 <script> 标签（如 Astro Islands），而 "use server" 则告诉捆绑程序生成 POST 端点（如 tRPC Mutations）。两者结合在一起，你就可以编写可重复使用的组件，将客户端的交互性与相关的服务器端逻辑结合在一起。

Document Metadata：我们添加了内置支持，可在组件树的任意位置呈现 <title>、<meta> 和元数据 <link> 标记。这些标签在所有环境中都以相同的方式工作，包括完全客户端代码、SSR 和 RSC。这为 React Helmet 等库首创的功能提供了内置支持。

Asset Loading：我们将 Suspense 与样式表、字体和脚本等资源的加载生命周期集成在一起，这样 React 就能将它们考虑在内，以确定 <style>、<link> 和 <script> 等元素中的内容是否已准备好显示。我们还添加了 Resource Loading API（如 preload 和 preinit），以便更好地控制资源加载和初始化的时间。

Actions：如上所述，我们添加了Actions来管理从客户端向服务器发送数据。您可以向 <form/> 等元素添加操作，使用 useFormStatus 访问状态，使用 useFormState 处理结果，以及使用 useOptimistic 积极地更新用户界面。

由于所有这些功能都是协同工作的，因此很难在稳定通道中单独发布。在发布 Actions 的同时，如果不提供用于访问表单状态的辅助钩子，将会限制 Actions 的实际可用性。引入 React 服务器组件而不集成服务器操作会使服务器上的数据修改变得复杂。

在将一组功能发布到稳定版渠道之前，我们需要确保这些功能能够协同工作，并且开发人员能够获得在生产中使用这些功能所需的一切。React Canaries 允许我们单独开发这些功能，并逐步发布稳定 API，直到整个功能集完成。

React Canary 中的当前功能集已经完成，可以随时发布。

React 的下一个主要版本：React 19
经过几年的迭代，react@canary 现已准备好向 react@latest 移植。上述新功能兼容您的应用所运行的任何环境，提供了生产使用所需的一切。由于资源加载和文档元数据可能会对某些应用程序造成破坏性改变，因此 React 的下一个版本将是一个重要版本：React 19。

我们还有更多工作要做，以便为发布做好准备。在 React 19 中，我们还将添加一些长期以来一直要求进行改进的功能，这些改进需要进行破坏性更改，例如对 Web Components 的支持。我们现在的重点是完成这些更改，为发布做好准备，最终确定新功能的文档，并发布包含哪些功能的公告。

我们将在接下来的几个月中分享更多信息，包括 React 19 包含的所有功能、如何采用新的客户端功能以及如何构建对 React Server Components 的支持。

Offscreen（更名为“Activity”）
自上次更新后，我们将正在研究的一项功能从 "Offscreen" 更名为 "Activity"。Offscreen 这个名称意味着它只适用于应用程序中不可见的部分，但在研究该功能时，我们意识到应用程序的部分内容有可能是可见而不活动的，例如模态后面的内容。新名称更贴切地反映了将应用程序的某些部分标记为 "active" 或 "inactive" 的行为。

Activity 仍在研究中，我们剩余的工作是最终确定向库开发人员公开的基元。我们已将这一领域列为优先事项，同时专注于提供更完整的功能。
更多参考：https://react.dev/blog/2024/02/15/react-labs-what-we-have-been-working-on-february-2024