React 16.x 藍圖[雙語版]

React · 發表 2018-12-02 12:06:48

摘要：本文來源:reactjs.org/blog/2018/1… LISENCE:Creative Commons Attribution 4.0 International 本文采用中文/英文對譯(不支援 IE/Edge...

本文來源:ofollow,noindex">reactjs.org/blog/2018/1…
LISENCE:ICENSE-DOCS.md" rel="nofollow,noindex">Creative Commons Attribution 4.0 International
本文采用中文/英文對譯(不支援 IE/Edge 瀏覽器), 點選中文即顯示英文原文, 希望能對你的英語有所幫助. 如有錯誤, 歡迎讀者指正
譯者:蔣璇 , 就職於丁香園, 任職Insight 醫藥資料庫前端開發. 開源社群熱愛者

React 16.x 藍圖 2018年11月27號,Dan Abramov

React 16.x Roadmap November 27, 2018 by Dan Abramov

你可能在之前的文章和演講中已經聽說過這些特性, 比如 "Hooks", "Suspense", 和 "Concurrent Rendering". 在該博文中, 我們將看一下怎麼將它們融合在一起和它們在 React 穩定版中可用的預期時間線.

You might have heard about features like "Hooks", "Suspense", and "Concurrent Rendering" in the previous blog posts and talks. In this post, we’ll look at how they fit together and the expected timeline for their availability in a stable release of React.

簡而言之

tl;dr

我們計劃把 React 新特性的推出分為以下幾個里程碑:

React 16.6:為了程式碼分割的 Suspense(已經發布 )
React 16.9:為了資料獲取的 Suspense(~mid 2019)

We plan to split the rollout of new React features into the following milestones:

React 16.6: Suspense for Code Splitting (already shipped)
React 16.7: React Hooks (~Q1 2019)
React 16.8: Concurrent Mode (~Q2 2019)
React 16.9: Suspense for Data Fetching (~Q3 2019)

這些都是預計, 細節可能會隨著我們的推進而改變. 這裡還有至少兩個專案我們打算在 2019 年完成, 它們需要更多的探索並且還沒有和特定的版本捆綁在一起.

為了服務端渲染的 Suspense

These are estimates, and the details may change as we’re further along. There’s at least two more projects we plan to complete in 2019. They require more exploration and aren’t tied to a particular release yet:

Modernizing React DOM
Suspense for Server Rendering

我們預計在接下來的幾個月會更加清晰它們的釋出時間線

We expect to get more clarity on their timeline in the coming months.

注意:

該文章只是一個藍圖 — 其中沒有任何內容需要您立即關注. 當釋出每一個功能時, 我們會發布一篇完整的文章宣佈它們.

This post is just a roadmap — there is nothing in it that requires your immediate attention. When each of these features are released, we’ll publish a full blog post announcing them.

釋出時間線

Release Timeline

我們對所有的這些功能如何組合在一起有個想法, 但我們會在每一個部分準備就緒之後釋出它, 以便於你可以更快的測試並使用它們.在單獨檢視它們的時候, API 的設計看起來不是那麼合理; 這篇文章列出了我們計劃的主要部分, 它可以幫助你瞭解整體情況.(參閱我們的版本策略, 瞭解我們對於穩定性的承諾)

We have a single vision for how all of these features fit together, but we’re releasing each part as soon as it is ready so that you can test and start using them sooner. The API design doesn’t always make sense when looking at one piece in isolation; this post lays out the major parts of our plan to help you see the whole picture. (See our versioning policy to learn more about our commitment to stability.)

逐步釋出策略可以幫助我們優化 API, 但是在某些事情尚未準備就緒的過渡時期可能令人感到迷惑. 讓我們看一下不同的功能對於您的應用程式意味著什麼, 他們如何關聯, 以及何時開始學習和使用它們.

The gradual release strategy helps us refine the APIs, but the transitional period when some things aren’t ready can be confusing. Let’s look at what these different features mean for your app, how they relate to each other, and when you can expect to start learning and using them.

React 16.6: 為了程式碼分割的 Suspense (已釋出)

React 16.6: Suspense for Code Splitting (shipped)

Suspense 是指 React 在元件等待某事時 "暫停" 渲染的新功能, 並且顯示一個 loading 指示器. 在 React 16.6 中, Suspense 只支援一個使用場景: 懶載入元件使用React.lazy() and<React.Suspense> .

Suspense refers to React’s new ability to "suspend" rendering while components are waiting for something, and display a loading indicator. In React 16.6, Suspense supports only one use case: lazy loading components withReact.lazy() and<React.Suspense> .

const OtherComponent = React.lazy(() => import('./OtherComponent'));

function MyComponent() {
return (
<React.Suspense fallback={<Spinner />}>
<div>
<OtherComponent />
</div>
</React.Suspense>
);
}
複製程式碼

程式碼分割指南中記錄了使用React.lazy() 和<React.Suspense> 來實現程式碼分割. 你可以在本文中找到另一個實用的解釋

Code splitting withReact.lazy() with<React.Suspense> is documented in the Code Splitting guide. You can find another practical explanation in this article.

在 Facebook, 從七月份就已經開始使用 Suspense 來進行程式碼分割, 並期望它保持穩定. 在 16.6.0 的初始公開發布中有一些迴歸, 但它們在 16.6.3 中得以修復.

We have been using Suspense for code splitting at Facebook since July, and expect it to be stable. There’s been a few regressions in the initial public release in 16.6.0, but they were fixed in 16.6.3.

程式碼分割只是 Suspense 的第一步. 我們對 Suspense 的長期遠景包括讓它處理資料獲取(並與像 Apollo 這樣的庫整合).除了方便的程式設計模型, Suspense 也在 Concurrent Mode 下提供更好的使用者體驗. 你將在下面找到有關這些主題的資訊.

Code splitting is just the first step for Suspense. Our longer term vision for Suspense involves letting it handle data fetching too (and integrate with libraries like Apollo). In addition to a convenient programming model, Suspense also provides better user experience in Concurrent Mode. You’ll find information about these topics further below.

React DOM: 從 React 16.6.0 可用

Status in React DOM: Available since React 16.6.0.

React DOM Server: 目前 Suspense 在服務端渲染中還不可用. 這不是因為缺乏關注. 我們已經開始研究一個新的非同步服務端渲染器, 其將支援 Suspense, 但是這是一個大型專案, 需要佔用 2019 年的大部分時間才能完成.

Status in React DOM Server: Suspense is not available in the server renderer yet. This isn’t for the lack of attention. We’ve started work on a new asynchronous server renderer that will support Suspense, but it’s a large project and will take a good chunk of 2019 to complete.

React Native: 拆包在 React Native 中並不是那麼有用. 但是在給模組 Promise 的時候, 沒有什麼技術阻止React.lazy() 和<Suspense> 工作.

Status in React Native: Bundle splitting isn’t very useful in React Native, but there’s nothing technically preventing React.lazy() and <Suspense> from working when given a Promise to a module.

建議: 如果你只進行客戶端渲染, 我們建議廣泛採用React.lazy() 和<React.Suspense> 進行程式碼拆分 React 元件. 如果你進行服務端渲染, 你則必須接受等待, 直到新的服務端渲染器準備就緒.

Recommendation: If you only do client rendering, we recommend widely adopting React.lazy() andfor code splitting React components. If you do server rendering, you’ll have to wait with adoption until the new server renderer is ready.

React 16.7: Hooks (~Q1 2019)

Hooks 允許你在函式元件中使用 state 和生命週期. 它們還允許你在元件之間重用有狀態的邏輯, 而無需在樹中引入無用的巢狀

Hooks let you use features like state and lifecycle from function components. They also let you reuse stateful logic between components without introducing extra nesting in your tree.

function Example() {
// Declare a new state variable, which we'll call "count"
const [count, setCount] = useState(0);

return (
<div>
<p>You clicked {count} times</p>
<button onClick={() => setCount(count + 1)}>
Click me
</button>
</div>
 );
}
複製程式碼

Hooks介紹和概述是個開始的好地方. 觀看這些演講, 瞭解視訊介紹和深度探討.FAQ 應該可以回答你的大多數問題. 要了解更多 Hooks 背後的動機, 你可以閱讀這篇文章. 這個 RFC 討論中解釋了 Hooks 的 API 設計的一些基本原理.

Hooks introduction and overview are good places to start. Watch these talks for a video introduction and a deep dive. The FAQ should answer most of your further questions. To learn more about the motivation behind Hooks, you can read this article. Some of the rationale for the API design of Hooks is explained in this RFC thread reply.

從九月開始, 在 Facebook 就已經開始內部測試 Hooks. 我們不希望在實施中出現重大 bug. Hooks 現在僅僅在 React的 16.7 alpha 版本中可用. 一些 API 預期有可能在最終的 16.7 版本中被改變(詳細資訊請參閱該評論的結尾部分)

We have been dogfooding Hooks at Facebook since September. We don’t expect major bugs in the implementation. Hooks are only available in the 16.7 alpha versions of React. Some of their API is expected to change in the final 16.7 version (see the end of this comment for details).

Hooks 代表著我們對於 React 未來的願景. 它們解決了 React 使用者直接體驗問題(render props和高階元件的 "wrapper hell", 生命週期方法中的邏輯重複), 以及我們遇到的大規模 React 優化的問題(例如使用編譯器在內聯元件上遇到的困難(譯者注: 詳細的 issue 可見here )). Hooks 不會拋棄類. 但是, 如果 Hooks 成功了, 有可能在一個未來的主版本中可能將類的支援移至一個單獨的包中, 來減少 React 的預設包尺寸.

Hooks represent our vision for the future of React. They solve both problems that React users experience directly (“wrapper hell” of render props and higher-order components, duplication of logic in lifecycle methods), and the issues we’ve encountered optimizing React at scale (such as difficulties in inlining components with a compiler). Hooks don’t deprecate classes. However, if Hooks are successful, it is possible that in a future major release class support might move to a separate package, reducing the default bundle size of 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 不會工作.

Status in React DOM:The first version of react and react-dom supporting Hooks is 16.7.0-alpha.0. We expect to publish more alphas over the next months (at the time of writing, the latest one is 16.7.0-alpha.2). You can try them by installing react@next with react-dom@next. Don’t forget to update react-dom — otherwise Hooks won’t work.

React DOM Server: react-dom 的 16.7 alpha 版本用react-dom/server 來完全支援 Hooks.

Status in React DOM Server: The same 16.7 alpha versions of react-dom fully support Hooks with react-dom/server.

React Native: 目前沒有任何官方的支援在 React Native 中嘗試 Hooks. 如果你喜歡冒險, 檢視此主題來獲取非官方指示. 這裡有一個已知問題,useEffect 被觸發的太晚, 仍然需要解決.

Status in React Native: There is no officially supported way to try Hooks in React Native yet. If you’re feeling adventurous, check out this thread for unofficial instructions. There is a known issue with useEffect firing too late which still needs to be solved.

建議: 當你準備好了, 我們鼓勵你在寫新元件時開始嘗試使用 Hooks.確保你的團隊中的每一個人都使用它們並熟悉本文件. 我們不建議你將已存在的類重寫為 Hooks, 除非你已經有計劃去重寫它們(例如: 修復 bugs). 在這裡閱讀有關採用策略的更多資訊.

Recommendation: When you’re ready, we encourage you to start trying Hooks in new components you write. Make sure everyone on your team is on board with using them and familiar with this documentation. We don’t recommend rewriting your existing classes to Hooks unless you planned to rewrite them anyway (e.g. to fix bugs). Read more about the adoption strategy here.

: Concurrent Mode (~Q2 2019)

React 16.8: Concurrent Mode (~Q2 2019)

Concurrent Mode 通過非阻塞主執行緒渲染元件樹來讓 React 應用程式更具響應性. 它是選擇性的加入, 並且允許 React 來中斷長時間的渲染(例如, 渲染新獲得的故事), 去處理高優先順序事件(例如, 文字輸入或者是 hover). Concurrent Mode 還通過在快速的網路連線環境中跳過不必要的 loading 狀態來改善 Suspense 的使用者體驗.

Concurrent Mode lets React apps be more responsive by rendering component trees without blocking the main thread. It is opt-in and allows React to interrupt a long-running render (for example, rendering a new feed story) to handle a high-priority event (for example, text input or hover). Concurrent Mode also improves the user experience of Suspense by skipping unnecessary loading states on fast connections.

注意:

你之前可能已經聽說過 Concurrent Mode 被稱為 "async mode". 我們已經將其名字改為 Concurrent Mode, 以突出顯示 React 在不同優先順序上執行工作的能力. 這使得它與其他非同步渲染的方法區別出來.

You might have previously heard Concurrent Mode being referred to as “async mode”. We’ve changed the name to Concurrent Mode to highlight React’s ability to perform work on different priority levels. This sets it apart from other approaches to async rendering.

// Two ways to opt in:

// 1. Part of an app (not final API)
<React.unstable_ConcurrentMode>
<Something />
</React.unstable_ConcurrentMode>

// 2. Whole app (not final API)
ReactDOM.unstable_createRoot(domNode).render(<App />);
複製程式碼

目前還沒有為 Concurrent Mode 寫文件. 重要的是強調, 概念模型最初有可能不熟悉. 記錄它的好處, 如何高效的使用它, 和它存在的缺陷是我們的高度優先事項, 並且將其稱為穩定的先決條件. 在此之前,Andrew 的演講是最好的介紹.

There is no documentation written for the Concurrent Mode yet. It is important to highlight that the conceptual model will likely be unfamiliar at first. Documenting its benefits, how to use it efficiently, and its pitfalls is a high priority for us, and will be a prerequisite for calling it stable. Until then, Andrew’s talk is the best introduction available.

Concurrent Mode 比 Hooks 更加精緻.一些 API 目前還沒有正確的 "連線", 並且沒有做到被期望的樣子. 在撰寫本文時,我們不建議將其用於除了早期試驗之外的任何事情. 我們預計併發模式本身並不存在很多錯誤, 但請注意, 在 <React.StrictMode> 中產生警告的元件可能無法正常工作. 另外, 我們已經看到 Concurrent Mode 在其他程式碼中面臨效能問題, 這些問題有時被誤認為是 Concurrent Mode 自身的效能問題. 例如, 一個執行在每毫秒的無主的setInterval(fn, 1) 呼叫在 Concurrent Mode 下將會有更差的影響. 我們計劃釋出更多關於診斷和解決此類問題的嚮導, 作為 16.8 釋出文件的一部分.

Concurrent Mode is much less polished than Hooks. Some APIs aren’t properly "wired up" yet and don’t do what they’re expected to. At the time of writing this post, we don’t recommend using it for anything except very early experimentation. We don’t expect many bugs in Concurrent Mode itself, but note that components that produce warnings inmay not work correctly. On a separate note, we’ve seen that Concurrent Mode surfaces performance problems in other code which can sometimes be mistaken for performance issues in Concurrent Mode itself. For example, a stray setInterval(fn, 1) call that runs every millisecond would have a worse effect in Concurrent Mode. We plan to publish more guidance about diagnosing and fixing issues like this as part of the 16.8 release documentation.

Concurrent Mode 是我們對於 React 願景的一個重要部分. 對於 CPU 密集型工作, 它允許非阻塞渲染, 並在渲染複雜元件樹的時候保持你的應用程式的響應. 這是我們在 JSConf 冰島演講的第一部分演示的. Concurrent 也令 Suspense 更好. 它允許你避免閃爍載入 loading 指示器, 如果網路足夠快. 但是沒有看到例項很難解釋, 所以Andrew 的演講是目前最好的資源. Concurrent Mode 依賴於協作主執行緒排程程式, 我們正在與 Chrome 團隊合作, 最終將此功能帶到瀏覽器本身.

Concurrent Mode is a big part of our vision for React. For CPU-bound work, it allows non-blocking rendering and keeps your app responsive while rendering complex component trees. That’s demoed in the first part of our JSConf Iceland talk. Concurrent Mode also makes Suspense better. It lets you avoid flickering a loading indicator if the network is fast enough. It’s hard to explain without seeing so Andrew’s talk is the best resource available today. Concurrent Mode relies on a cooperative main thread scheduler, and we are collaborating with the Chrome team to eventually move this functionality into the browser itself.

React DOM: 一個非常不穩定的 Concurrent Mode 版本, 在 React 16.6 中以unstable_ 字首存在, 但是我們不推薦嘗試它, 除非你願意經常遇到障礙或者缺少功能. 16.7 alpha 版本包括沒有unstable__ 字首的React.ConcurrentMode 和ReactDOM.createRoot , 但是我們可能在 16.7 中保持字首, 並且只在 React 16.8 中記錄和標記 Concurrent Mode 為穩定.

Status in React DOM: A very unstable version of Concurrent Mode is available behind an unstable_ prefix in React 16.6 but we don’t recommend trying it unless you’re willing to often run into walls or missing features. The 16.7 alphas include React.ConcurrentMode and ReactDOM.createRoot without an unstable_ prefix, but we’ll likely keep the prefix in 16.7, and only document and mark Concurrent Mode as stable in React 16.8.

React DOM Server: Concurrent Mode 不會直接影響服務端渲染. 它將工作在已經存在的服務端渲染中.

Status in React DOM Server: Concurrent Mode doesn’t directly affect server rendering. It will work with the existing server renderer.

React Native: 目前的計劃是延遲在 React Native 中啟用 Concurrent Mode, 直到React Fabric 專案接近完成.

Status in React Native: The current plan is to delay enabling Concurrent Mode in React Native until React Fabric project is near completion.

建議: 如果你希望在未來採用 Concurrent Mode, 在<React.StrictMode> 中包裝一些元件子樹並修復生成的警告是很好的第一步. 通常, 舊程式碼預計不會立即相容. 例如, 在 Facebook, 我們主要打算在最近開發的程式碼庫中使用 Concurrent Mode, 並在不久的將來保持舊程式碼執行在同步模式下.

Recommendation: If you wish to adopt Concurrent Mode in the future, wrapping some component subtrees inand fixing the resulting warnings is a good first step. In general it’s not expected that legacy code would immediately be compatible. For example, at Facebook we mostly intend to use the Concurrent Mode in the more recently developed codebases, and keep the legacy ones running in the synchronous mode for the near future.

: 為了資料獲取的 Suspense (~mid 2019)

React 16.8: Concurrent Mode (~Q2 2019)

如前所述, Suspense 指的是能夠在元件等待某事的時候 "暫停" 渲染的能力, 並且顯示一個 loading 指示器. 在已經發布的 16.6 版本中, Suspense 唯一支援的使用場景就是程式碼分割. 在未來的 16.9 版本中, 我們還希望在使用它在為了獲取資料的場景下提供官方的支援. 我們將提供與 Suspense 相容的一個基礎的 "React Cache" 的參考實現, 但是你也可以寫一個你自己的. 資料獲取庫, 像 Apollo 和 Relay, 將能夠通過遵循我們將要記錄的簡單規範來與 Suspense 整合.

As mentioned earlier, Suspense refers to React’s ability to “suspend” rendering while components are waiting for something, and display a loading indicator. In the already shipped React 16.6, the only supported use case for Suspense is code splitting. In the future 16.9 release, we’d like to provide officially supported ways to use it for data fetching too. We’ll provide a reference implementation of a basic "React Cache" that’s compatible with Suspense, but you can also write your own. Data fetching libraries like Apollo and Relay will be able to integrate with Suspense by following a simple specification that we’ll document.

// React Cache for simple data fetching (not final API)
import {unstable_createResource} from 'react-cache';

// Tell React Cache how to fetch your data
const TodoResource = unstable_createResource(fetchTodo);

function Todo(props) {
// Suspends until the data is in the cache
const todo = TodoResource.read(props.id);
return <li>{todo.title}</li>;
}

function App() {
return (
// Same Suspense component you already use for code splitting
// would be able to handle data fetching too.
<React.Suspense fallback={<Spinner />}>
<ul>
{/* Siblings fetch in parallel */}
<Todo id="1" />
<Todo id="2" />
</ul>
</React.Suspense>
);
}

// Other libraries like Apollo and Relay can also
// provide Suspense integrations with similar APIs.
複製程式碼

目前還沒有官方的文件說明如何使用 Suspense 獲取資料, 但是你可以在此演講和這個小型 demo 中找到一些早期資訊. 我們將在 React 16.9 釋出左右編寫 React Cache 的文件(以及如何編寫自己的 Suspense 相容庫), 但是如果你很好奇, 你可以在這裡找到它的非常早期的原始碼

There is no official documentation for how to fetch data with Suspense yet, but you can find some early information in this talk and this small demo. We’ll write documentation for React Cache (and how to write your own Suspense-compatible library) closer to the React 16.9 release, but if you’re curious, you can find its very early source code here.

其實在 React 16.6 中, 底層 Suspense 機制(暫停渲染並且顯示 loading 元件)就預計穩定了. 我們已經在生產環境中使用它用來程式碼分割數月了. 但是, 用來資料獲取的上層 API 還非常不穩定. React Cache 正在迅速變化, 並且至少會改變幾次.有一些底層的 API 缺少高階 API 可用. 除非是早期試驗, 否則我們不建議在任何地方使用 React Cache. 注意 React Cache 自身並不嚴格依賴於 React 版本, 而且當前的 alphas 版本缺少基礎特性, 例如快取失效. 你很快就會遇到障礙. 我們預計在 React 16.9 版本中有一些東西可用.

The low-level Suspense mechanism (suspending rendering and showing a fallback) is expected to be stable even in React 16.6. We’ve used it for code splitting in production for months. However, the higher-level APIs for data fetching are very unstable. React Cache is rapidly changing, and will change at least a few more times. There are some low-level APIs that are missing for a good higher-level API to be possible. We don’t recommend using React Cache anywhere except very early experiments. Note that React Cache itself isn’t strictly tied to React releases, but the current alphas lack basic features as cache invalidation, and you’ll run into a wall very soon. We expect to have something usable with the React 16.9 release.

最終我們希望通過 Suspense 來獲取大多數資料, 但是這需要很長的事件, 直到所有的整合都準備就緒. 在實踐中, 我們期望可以使用非常遞進式的採用, 並且通常通過 Apollo 和 Relay 這樣的中間層使用, 而不是直接使用. 缺少上層 API 並不是唯一的障礙 — 還有有些非常重要的 UI 模式我們還沒有支援, 例如在載入器檢視層次結構之外顯示進度指示器. 與往常一樣, 我們將在本部落格的釋出說明中傳達我們的進展.

Eventually we’d like most data fetching to happen through Suspense but it will take a long time until all integrations are ready. In practice we expect it to be adopted very incrementally, and often through layers like Apollo or Relay rather than directly. Missing higher level APIs aren’t the only obstacle — there are also some important UI patterns we don’t support yet such as showing progress indicator outside of the loading view hierarchy. As always, we will communicate our progress in the release notes on this blog.

React DOM 和 React Native: 從技術的角度來看, 在 React 16.6 中一個相容的 cache 就已經可以和<React.Suspense> 工作了. 但是, 在 React 次級版本釋出之前我們還沒有擁有一個好的 cache 實現. 如果你是敢於冒險的, 你可以通過檢視 React Cache alphas 來嘗試寫一個你自己的 cache. 但是, 請注意, 心智模型(譯者注: 關於心智模型見here)是完全不同的, 在文件準備好之前誤解的可能性非常高.

Status in React DOM and React Native: Technically, a compatible cache would already work with<React.Suspense> in React 16.6. However, we don’t expect to have a good cache implementation until this React minor release. If you’re feeling adventurous, you can try to write your own cache by looking at the React Cache alphas. However, note that the mental model is sufficiently different that there’s a high risk of misunderstanding it until the docs are ready.

React DOM Server: 目前 Suspense 在服務端渲染中還不可用. 正如我們前面提到的, 我們已經開始研究一個新的非同步服務端渲染器，它將支援Suspense，但它是一個大型專案，需要2019年的大部分時間才能完成.

Status in React DOM Server: Suspense is not available in the server renderer yet. As we mentioned earlier, we’ve started work on a new asynchronous server renderer that will support Suspense, but it’s a large project and will take a good chunk of 2019 to complete.

建議: 為了使用資料獲取的 Suspense, 請等待該 React 次級版本釋出. 不要在 16.6 版本中嘗試為了資料獲取使用 Suspense 特性; 還不支援. 但是當資料獲取的 Suspense 成為官方支援的時候, 現存的為了程式碼分割的 <Suspense> 元件也將可以正常顯示 loading 狀態.

Recommendation: Wait for this minor React release in order to use Suspense for data fetching. Don’t try to use Suspense features in 16.6 for it; it’s not supported. However, your existingcomponents for code splitting will be able to show loading states for data too when Suspense for Data Fetching becomes officially supported.

其他專案

Other Projects

讓 React DOM 更加現代化

Modernizing React DOM

我們開始調查 ReactDOM 的簡化和現代化 , 目標是減小包的尺寸並且和瀏覽器的行為更緊密的對齊. 因為現在該專案還處於早期探索階段, 現在說哪些要點將要 "成功" 還為時過早. 我們將在這個issue(譯者注: 上面的簡化和現代化的 issue 連結) 上面傳遞我們的進展.

We started an investigation into simplifying and modernizing ReactDOM, with a goal of reduced bundle size and aligning closer with the browser behavior. It is still early to say which specific bullet points will “make it” because the project is in an exploratory phase. We will communicate our progress on that issue.

服務端渲染的 Suspense

Suspense for Server Rendering

我們開始設計一個新的服務端渲染器, 其支援 Suspense(包括在伺服器上面等待非同步渲染資料而不進行雙重渲染), 並逐步載入和用 chunks 合成頁面內容來獲得最佳的使用者體驗.你可以在本次演講中觀看其早期原型的概述. 這個新的服務端渲染器將成為我們2019年的主要焦點, 但是現在說關於它的釋出計劃還為時過早. 它的發展, 將一如既往的發生在 github 上面 ,

We started designing a new server renderer that supports Suspense (including waiting for asynchronous data on the server without double rendering) and progressively loading and hydrating page content in chunks for best user experience. You can watch an overview of its early prototype in this talk. The new server renderer is going to be our major focus in 2019, but it’s too early to say anything about its release schedule. Its development, as always, will happen on GitHub.

僅此而已, 正如你所看到的, 這裡有很多事情讓我們忙碌, 但是我們期待在接下來的幾個月取得更多進展.

And that’s about it! As you can see, there’s a lot here to keep us busy but we expect much progress in the coming months.

我們希望該文章能讓你瞭解到我們正在開展的工作, 今天你可以使用什麼, 以及在未來你可以使用什麼. 雖然在社交平臺上面有很多關於新特性的討論, 但是如果你閱讀了該篇文章, 你將不會錯過任何重要的東西.

We hope this post gives you an idea of what we’re working on, what you can use today, and what you can expect to use in the future. While there’s a lot of discussion about new features on social media platforms, you won’t miss anything important if you read this blog.

我們始終樂於接受反饋, 並且希望在RFC repository ,issue tracker ,Twitter 上面聽到你的聲音

We’re always open to feedback, and love to hear from you in the RFC repository, the issue tracker, and on Twitter.

譯者注:

譯者並不精通英語, 但是深知英語對於程式設計師的重要性, 所以譯者在翻譯的時候保留了英語原文, 希望給你一個原滋原味的閱讀體驗並且能熟悉一些常見的英文.

希望有讀者可以指出我的翻譯錯誤, 感激不盡.

譯文轉載請註明出處

React 16.x 藍圖[雙語版]

您可能也會喜歡…