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国际技术”致力于与你共享高质量的技术文章

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