React18，不遠啦？

時間 2021-06-02

標籤 html 前端 react git github 算法瀏覽器網絡併發 app 欄目 React 简体版

原文原文鏈接

在React前不久的一次PR #21488中，核心成員Brian Vaughn對React內一些API、以及內部flag做出調整。html

其中最引人注目的改動是：React入口增長createRoot API。前端

業界將這一變化解讀爲：Concurrent Mode（後文簡稱爲CM）將在不久後穩定，並出如今正式版中。react

React17是一個過渡版本，用以穩定CM。一旦CM穩定，那v18的進度會大大加快。git

能夠說從18年到21年，React團隊的主要工做就是圍繞CM展開的，那麼：github

CM是什麼？
CM能解決React什麼問題？
爲何經歷快4年，跨越1六、17兩個版本，CM還不穩定？

本文將做出解答。算法

CM是什麼

要了解CM（併發模式）是什麼，首先須要知道React源碼的運行流程。瀏覽器

React大致能夠分爲兩個工做階段：網絡

render階段

在render階段會計算一次更新中變化的部分（經過diff算法），因組件的render函數在該階段調用而得名。併發

render階段可能是異步的（取決於觸發更新的場景）。app

commit階段

在commit階段會將render階段計算的須要變化的部分渲染在視圖中。對應ReactDOM來講會執行appendChild、removeChild等。

commit階段必定是同步調用（這樣用戶不會看到渲染不徹底的UI）

咱們經過ReactDOM.render建立的應用屬於legacy模式。

在該模式下一次render階段對應一次commit階段。

若是咱們經過ReactDOM.createRoot（當前穩定版本中尚未此API）建立的應用屬於開篇提到的CM（concurrent模式）

在CM下，更新有了優先級的概念，render階段可能被高優先級的更新打斷。

因此render階段可能會重複屢次（被打斷後從新開始）。

可能屢次render階段對應一次commit階段。

此外，還有個blocking模式用於方便開發者慢慢從legacy模式過渡到CM。

你能夠從特性對比看到不一樣模式支持的特性：

爲何須要CM？

知道了CM是什麼，那麼他有什麼用？爲何React核心團隊會耗時3年多（18年開始）來實現他？

這得從React的設計理念聊起。

咱們能夠從官網React哲學看到React的設計理念：

咱們認爲， React是用 JavaScript構建 快速響應的大型 Web應用程序的首選方式。

其中快速響應是重點。

那麼什麼影響快速響應呢？React團隊給出的答案：

CPU的瓶頸和 IO的瓶頸

CPU的瓶頸

考慮以下demo，咱們渲染3000的列表項：

function App() {
  const len = 3000;
  return (
    <ul>
      {Array(len).fill(0).map((_, i) => <li>{i}</li>)}
    </ul>
  );
}

const rootEl = document.querySelector("#root");
ReactDOM.render(<App/>, rootEl);

剛纔說過，在legacy模式下render階段不會被打斷，則這3000個li的render都得在同一個瀏覽器宏任務中完成。

長時間的計算會阻塞線程，形成頁面掉幀，這就是CPU的瓶頸。

解決的辦法就是：啓用CM，將render階段變爲可中斷的，

當瀏覽器一幀剩餘時間很少時將控制權交給瀏覽器。等下一幀的空餘時間再繼續組件render。

IO的瓶頸

除了長時間計算致使的卡頓，網絡請求時的loading狀態也會形成頁面不可交互，這就是IO的瓶頸。

IO瓶頸是客觀存在的。

做爲前端，能作的只能是儘早請求須要的數據。

可是，一般狀況下：代碼可維護性與請求效率是相悖的。

什麼意思呢，舉個例子：

假設咱們封裝了請求數據的方法useFetch，經過返回值是否存在區分是否請求到數據。

function App() {
  const data = useFetch();
  
  return {data ? <User data={data}/> : null};
}

爲了提升代碼可維護性，useFetch與要渲染的組件User存在於同一個組件App中。

然而，若是User組件內還須要進一步請求數據呢（以下profile數據）？

function User({data}) {
  const {id, name} = data?.id || {};
  const profile = useFetch(id);
  
  return (
    <div>
      <p>{name}</p>
      {profile ? <Profile data={profile} /> : null}
    </div>
  )
}

本着代碼可維護性原則，useFetch與要渲染的組件Profile存在於同一個組件User中。

可是，這樣組織代碼，Profile組件只能等User render後再render。

數據只能像瀑布的水同樣，一層一層流下來。

這種低效的請求數據方式被稱爲waterfall。

爲了提升請求效率，咱們能夠將「請求Profile組件所需數據的操做」提到App組件內，合併在useFetch中：

function App() {
  const data = useFetch();
  
  return {data ? <User data={data}/> : null};
}

可是這樣就下降了代碼可維護性（Profile組件離profile數據太遠）。

React團隊從Relay團隊借鑑經驗，藉助Suspense特性，提出了Server Components。

就是爲了在處理IO瓶頸時兼顧代碼可維護性與請求效率。

這一特性的實現須要CM中更新有不一樣優先級。

CM爲何花費這麼久？

接下來，咱們從源碼、特性、生態三個方面，自底向上看看CM的普及有多麼不容易。

源碼層面

優先級算法改造

在v16.13以前，React已經實現了基本的CM功能。

咱們以前聊過，CM有更新優先級的概念。以前是經過一個毫秒數expirationTime標記更新的過時時間。

經過對比不一樣更新的expirationTime判斷優先級高低
經過對比更新的expirationTime與當前時間判斷更新是否過時（過時須要同步執行）

可是，expirationTime做爲一個與時間相關的浮點數，沒法表示一批優先級這個概念。

爲了實現更上層的Server Components特性，須要有一批優先級這個概念。

因而，核心成員Andrew Clark開始了曠日持久的優先級算法改造，見：PR lanes

Offscreen支持

在此同時，另外一個成員Luna Ruan在開發一個新API —— Offscreen。

能夠理解這是React版的Keep-Alive特性。

訂閱外部源

未開啓CM前，在一次更新以下三個生命週期只會調用一次：

componentWillMount
componentWillReceiveProps
componentWillUpdate

可是開啓CM後，因爲render階段可能被打斷、重複，因此他們可能被調用屢次。

在訂閱外部源（好比註冊事件回調）時，可能更新不及時或者內存泄漏。

舉個例子：bindEvent是一個基於發佈訂閱的外部依賴（好比一個原生DOM事件）：

class App {
  componentWillMount() {
    bindEvent('eventA', data => {
      thie.setState({data});
    });
  }
  componentWillUnmount() {
    bindEvent('eventA');
  }
  render() {
    return <Card data={this.state.data}/>;
  }
}

在componentWillMount中綁定，在componentWillUnmount中解綁。

當接收到事件後，更新data。

當render階段反覆中斷、暫停後，有可能出現：