原文作者：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
好文推薦：
“UC國際技術”致力於與你共享高質量的技術文章
歡迎關注我們的公眾號、將文章分享給你的好友
