React 16.x 路线图公布，包括服务器渲染的 Suspense 组件及Hooks等

原文作者：Dan Abramov

译者：UC 国际研发 Jothy

写在最前：欢迎你来到“UC国际技术”公众号，我们将为大家提供与客户端、服务端、算法、测试、数据、前端等相关的高质量技术文章，不限于原创与翻译。

你可能已经在之前的博文和演讲中听说过“Hooks”，“Suspense” 和 “Concurrent Rendering”等功能。 在这篇文章中，我们将看看如何组合使用它们，并给出它们在 React 稳定版中的预计可用时间表。

快速预览版

我们计划分以下里程碑推出 React 新功能：

• React 16.6：支持代码拆分的 Suspense 组件（已经发布）

• React 16.7：React Hooks（~ 2019 年 Q1）

• React 16.8：并发模式（~ 2019 年 Q2）

• React 16.9：支持数据提取的 Suspense 组件（~ 2019 年年中）

这些时间都是预估的，细节可能随着我们的进展而变化。 我们计划在 2019 年完成至少两个项目。它们仍需更多的探索，而且还没有关联上特定版本：

• 现代化 React DOM

• 支持服务器渲染的 Suspense 组件

我们计划在接下来几个月内给出一份更清晰的时间表。

注意

这篇文章只是一份路线图 - 其中没有任何需要你立即关注的内容。 每当有功能发布，我们都将发表完整的告知博文。

发布时间表

我们也会幻想这些功能组合在一起会是什么样子的，但是为了你能尽早使用它们，每个部分 ready 后我们都会立即发布。 当你独立看某个 API 时，它的设计并不总是有意义的; 这篇文章中，我们列出了计划的核心部分，以让你了解整体情况。（请参阅我们的版本条例，了解有关我们对稳定性的承诺。）

逐步发布策略有助于我们优化 API，但未完待续的过渡时期可能会给大家带来困扰。 我们来看看这些不同的功能对你的 App 来说意味着什么，它们之间是如何关联的，以及何时可以开始学习使用它们。

>> React 16.6: 支持代码拆分的 Suspense 组件（已发布） <<

Suspense 指的是 React 在等待组件时“suspend（暂停）”渲染，并显示加载标识的新功能。 在 React 16.6 中，Suspense 只支持一个场景：使用 React.lazy() 和 <React.Suspense> 实现的懒加载组件。

代码拆分指引中有使用 React.lazy() 与 <React.Suspense> 进行代码拆分的记载。这篇文章中也有另一种实用的解释。

自 7 月以来，我们一直在 Facebook 上使用 Suspense 进行代码分割，并期望它保持稳定。16.6.0 的初始版本中有一些 regression，不过都在 16.6.3 中修复了。

代码拆分只是 Suspense 的第一步。我们对 Suspense 的长期愿景包括让它处理数据获取（并与像 Apollo 这样的库集成）。除了方便的编程模型，Suspense 还提供了并发模式下更好的用户体验。你可以在下面找到相关主题的信息。

React DOM 中的状态 ：从React 16.6.0 开始可用。

React DOM Server 中的状态 ：Suspense 尚不支持服务端渲染。并不是因为它没人关注。我们已经开始研究一个新的支持 Suspense 的异步服务端渲染器，但它是一个大项目，得到 2019 年差不多才能完成。

React Native 中的状态 ：Bundle 拆分在 React Native 中不是很有用，但是当模块是 Promise 时，React.lazy() 和 <Suspense> 将派上用场。

建议： 如果是做客户端渲染，我们建议多用 React.lazy() 和 <React.Suspense> 对 React 组件进行代码拆分。如果是做服务器渲染，请等待新的服务端渲染器 ready。

>> React 16.7: Hooks (~ 2019 Q1) <<

Hooks 让你可以使用功能组件的状态和生命周期等功能，以及在不引入额外嵌套的情况下，在组件之间重用状态逻辑。

你可以从 Hooks 的介绍和概述开始。观看这些演讲，了解它的介绍及深度探讨。FAQ应该能解答你的大多数问题。要了解更多 Hooks 的设计动机，你可以阅读 “Making Sense of React Hooks” 这篇文章。这个 RFC 回复 解释了 Hooks API 的一些基本设计原理。（注：相关链接请见原文）

自 9 月份以来，我们一直在 Facebook 上试用 Hooks。我们预计不会出现重大 bug。Hooks 仅适用于 React 16.7 alpha 版本。在 最终的16.7 版本中，部分 API 可能会有变化。

Hooks 代表了我们对 React 未来的期望。它们解决了 React 用户直接遇到的问题（渲染 props 和高阶组件的“封装地狱”，生命周期方法中的逻辑重复），以及我们进行大规模优化 React 时遇到的问题（例如使用编译器内联组件的难点）。Hooks 不会淘汰 class。但是如果 Hooks 成功了，那在将来的核心版本里，class 可能会被移动到单独的包中，以减少 React 的默认包大小。

React DOM 中的状态 ：第一个支持 Hooks 的 react 和 react-dom 的版本是 16.7.0-alpha.0。接下来的几个月里我们将发布更多的 alphas 版本（在撰写本文时，最新版本为 16.7.0-alpha.2）。你可以使用 react@next 和 react-dom@next 来尝鲜。不要忘记更新 react-dom - 否则 Hooks 将不起作用。

React DOM Server 中的状态 ：同样是 16.7 alpha 版本的 react-dom 完全支持 react-dom/server Hooks。

React Native 中的状态 ：目前官方仍未支持 React Native Hooks。如果你爱探险，请查看 原文链接 获取非官方指引。 已知 useEffect 会触发问题，但还没解决。

建议： 如果你准备好了，我们鼓励你在新组件中尝试使用 Hooks。确保团队成员都使用它们并熟悉文档。我们不建议将现有类重写为 Hooks，除非你本来就计划重写（例如修复 bug）。请查看这里获得更多使用策略。

>> React 16.8: 并发模式 (~ 2019 Q2) <<

并发模式在不阻塞主线程的情况下渲染组件树，使 React 应用响应性更好。 它是可选的，并允许 React 中断耗时的渲染（例如，渲染新的feed story）以处理高优事件（例如，文本输入或悬停）。 并发模式还能在高速连接时跳过不必要的加载状态，来改善 Suspense 的用户体验。

注意

你可能听过有人把并发模式称为“异步模式”。 我们已把它正式更名为“并发模式”，以凸显 React 针对不同优先级的执行能力。 这使它有别于其他异步渲染方案。

目前并发模式还没有文档。需要强调，这个概念模型最初可能比较陌生。我们把记录它的优缺点和用法列为高优事项，并且会作为稳定调用它的先决条件。在此之前，Andrew 的演讲是最好的介绍（视频请查看英文原文）。

并发模式不及 Hooks 那样精致。有些 API 尚未正确“连接”，并且表现不如预期。在撰写本文时，我们不建议将其用于除早期实验之外的任何用途。并发模式本身可能不会存在很多 bug，但在 <React.StrictMode> 中产生警告的组件可能无法正常工作。另外，我们发现并发模式在其他代码中有性能问题，这些问题有时会被误认为是并发模式本身的性能问题。例如，每毫秒运行的 setInterval(fn, 1) 调用在并发模式下会产生更差的效果。我们计划将更多关于诊断和解决此类问题的指导，作为 16.8 发布文档的一部分发布。

并发模式是 React 愿景的重要组成部分。对于受 CPU 限制的情况，它允许非阻塞渲染，使程序在渲染复杂组件树时保持响应。正如JSConf 冰岛演讲中第一部分展示的那样。并发模式也优化了 Suspense。它能在高速网络连接时避免闪烁加载标识。你得看到 Andrew 的演讲才能比较好地理解这些。并发模式依赖协作主线程调度程序，我们正在与 Chrome 团队协商将此功能移至浏览器。

React DOM 中的状态 ：React 16.6 支持带有 unstable_ 前缀的极不稳定并发模式版本，但是我们不建议尝试它，除非你想经常碰壁或缺少功能。 16.7 alpha 包含不带 unstable_ 前缀的 React.ConcurrentMode 和 ReactDOM.createRoot，但有可能 16.7 版本会保留该前缀，并且只在 React 16.8 中把并发模式标为稳定。

React DOM Server 中的状态 ：并发模式不会直接影响服务端渲染。它支持现有的服务端渲染器。

React Native 中的状态 ：当前计划是延迟弃用 React Native 中的并发模式，直到 React Fabric 项目接近完成。

建议： 如果你想使用并发模式，你可以先在 <React.StrictMode> 中包装组件子树并修复生成的警告。通常遗留代码不会立即兼容。例如，在 Facebook，我们主要打算在近期开发的代码库中使用并发模式，并在不久的将来保持传统的代码模式在同步模式下运行。

>> React 16.9: 支持数据获取的 Suspense 组件(~2019 年年中) <<

如前所述，Suspense 指的是 React 能够在组件等待时“暂停”渲染，并显示加载标识。 在已经发布的 React 16.6 中，Suspense 唯一支持的场景是代码分割。 在之后的 16.9 版本中，我们还希望提供官方支持的方法来将其用于数据获取。 我们将提供与 Suspense 兼容的基本“React Cache”的参考用例，你也可以自己编写。 像 Apollo 和 Relay 这样的数据获取库将能够通过简单的规范与 Suspense 集成。

目前还没有关于如何使用 Suspense 获取数据的官方文档，但你可以在本次演讲和这个 小型演示 中找到一些早期信息。我们将在 React 16.9 版本前后编写 React Cache 的文档（以及如何编写自己的 Suspense 兼容库），如果你很好奇，可以在 这里 找到它的早期源代码。

即使在 React 16.6 中，低级（low-level） Suspense 机制（暂停渲染并显示回退）也会保持预期稳定。我们已经在生产环境用它进行代码分割数月。但是，用于数据获取的更高级 API 非常不稳定。 React Cache 正在快速变化，并且至少会改变几次。有一些低级 API 缺少高级 API 可用。除非是早期的实验，否则我们不建议在任何地方使用 React Cache。请注意，React Cache 本身并不严格依赖于 React 版本，但是当前的 alphas 缺少基本功能，因为缓存失效，你很快就会碰壁。我们期望在 React 16.9 版本中产出可用的东西。

最终我们希望通过 Suspense 获取大部分数据，但是所有集成都 ready 需要很长时间。在实践中，我们期望渐进地采用它，并且通常通过像 Apollo 或 Relay 这样的层而不是直接采用。缺少更高级别的 API 并不是唯一的障碍 - 我们还不支持一些重要的 UI 模式，例如在加载视图层次结构之外显示进度指示器。与往常一样，我们将在本博客的发行说明中报告进展。

React DOM 和 React Native 中的状态 ：从技术上讲，兼容的缓存已经可以与 React 16.6 中的 <React.Suspense> 一起使用。但是，在 React 16.9 之前，可能不会有良好的缓存实现。如果你有冒险精神，可以查看 React Cache alphas 来尝试编写自己的缓存。但是，请注意，心智模型是完全不同的，在文档准备好之前存在误解的风险很高。

React DOM Server 中的状态 ：Suspense 尚未在服务端渲染器中可用。如前所述，我们已经开始研究一个新的支持 Suspense 的异步服务端渲染器，但它是一个大项目，得到 2019 年才能差不多完成。

建议 ：等待 16.9 版本使用 Suspense 进行数据获取。不要试图在 16.6 中使用 Suspense 功能——它不受支持。但是，当 Suspense 正式支持数据获取时，现有的用于代码拆分的 <Suspense> 组件也将能够显示数据的加载状态。

其他项目

>> 现代 React DOM <<

我们开始调查 ReactDOM 的简化和现代化，目标是减小捆绑包大小并与浏览器行为更紧密地对齐。 由于该项目处于探索阶段，现在说哪些具体要点将“成功”还为时尚早。 我们将在这个问题上传达我们的进展。

>> 支持服务端渲染的 Suspense <<

我们在设计一个支持 Suspense 的新服务端渲染器（包括在服务器上等待异步数据而不进行双重渲染），并逐步加载和保护页面内容以获得最佳用户体验。 你可以在本次演讲中观看其早期原型的概述。 新的服务端渲染器将成为我们 2019 年的焦点，但现在谈发布时间还为时过早。 它的发展将照旧发在 GitHub 上。

就是这些！ 如你所见，它们让我们忙碌并快乐着，并且接下来的几个月会有大进展。

我们希望这篇文章能让你了解我们正在做什么，你目前以及将来可以使用功能。 虽然社媒上都讨论开了，但这篇博客能让你不错过任何重要内容。

英文原文：

https://reactjs.org/blog/2018/11/27/react-16-roadmap.html

好文推荐：

2019年前端面试都聊啥？一起来看看

“UC国际技术”致力于与你共享高质量的技术文章

欢迎关注我们的公众号、将文章分享给你的好友