以後沒有 React Concurrent Mode 了

大家好，我卡頌。

相信很多關注React的朋友都知道Concurrent Mode，他是React漸進升級策略的產物。

即然是策略，那就有可能調整，這不，根據 What happened to concurrent mode?[1]，在v18中將不會有Concurrent Mode了。

本文讓我們一起了解React漸進升級策略的演進過程。

React 新老架構的區別

可以認爲採用Fiber架構前的React只支持一種優先級：同步優先級，即所有更新是 “同步、不可中斷” 的形式。

採用Fiber架構後的React支持包括同步優先級在內的多種優先級，或者說新架構支持併發更新。

所以新架構可以模擬老架構的運行機制（即不開啓併發更新）。

當新架構開啓併發更新後，就能使用React爲了解決CPU的瓶頸、IO的瓶頸而設計的併發特性（Concurrent Feature），比如：

當前所有React版本一定屬於如下情況之一：

v16、v17 默認屬於情況 2。

之所以劃分多種情況，是因爲情況 4 的React一些行爲異於情況 1、2、3（比如部分以componentWill開頭的生命週期函數的調用時機發生變化），也就是說開啓併發更新可能造成老代碼不兼容。

爲了讓廣大開發者能夠平滑過渡，React團隊採用了**「漸進升級」**方案。

v16.3 新增了StrictMode，對開發者編寫的**「不符合併發更新規範的代碼」**作出提示，逐步引導開發者寫出規範代碼。

此時React團隊的**「漸進升級」**策略是：讓頁面中可以同時存在三種模式的應用，具體如下：

Legacy模式，通過ReactDOM.render(<App />, rootNode)創建的應用遵循該模式。默認關閉StrictMode，表現同情況 2
Blocking模式，通過ReactDOM.createBlockingRoot(rootNode).render(<App />)創建的應用遵循該模式，作爲從Legacy向Concurrent過渡的中間模式，默認開啓StrictMode，表現同情況 3
Concurrent模式，通過ReactDOM.createRoot(rootNode).render(<App />)創建的應用遵循該模式，默認開啓StrictMode，表現同情況 4

三種模式可用特性對比

在 v17 之前，大多數事件會冒泡到HTML元素，爲了讓同一個頁面下不同應用獨立，v17 之後事件會冒泡到應用所在根元素。

所以 v17 也被稱爲**「墊腳石」**版本，他是爲**「開啓併發更新」**做鋪墊的版本。

但是，根據社區的反饋，React 團隊意識到當前的**「漸進升級」**策略存在問題。

這三種模式影響的是整個應用，從Legacy升級到Blocking後，由於開啓StrictMode，整個應用的**「併發不兼容警告」**都會上報。從這個角度看，並沒有起到**「漸進升級」**的目的。

另一方面，開發者從新架構中獲益更多是由於使用了併發特性，即然新架構支持**「開關併發更新」**，完全可以在使用了併發特性後再開啓併發更新。這樣就只需在**「使用了併發特性的組件」**部分啓用StrictMode。

相比劃分三種模式，這種以**「是否使用併發特性」**作爲是否開啓併發更新的依據，更符合**「漸進升級」**中**「漸進」**的理念。

所以在 v18 中，不再有三種模式，統一使用ReactDOM.createRoot(rootNode).render(<App />)創建應用。當不使用併發特性時，表現如情況 3。使用併發特性後，表現如情況 4。

一句話總結：v18以後只會有併發特性，不會有併發模式。

作爲一個發展了 8 年之久的前端框架，要想推進社區完成帶有breaking change的迭代升級，註定是困難的。

我們也看到了React團隊在此確實付出很多心血。

想問問各位，還學得動麼？

[1]

What happened to concurrent mode?: https://github.com/reactwg/react-18/discussions/64

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/hiocM5u_6SfJy5Adcck-3Q