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國際技術」致力於與你共享高質量的技術文章

歡迎關注咱們的公衆號、將文章分享給你的好友