大家好，我卡頌。

在很多全面使用Hooks開(kāi)發(fā)的團(tuán)隊(duì)，唯一使用ClassComponent的場(chǎng)景就是「使用ClassComponent創(chuàng)建ErrorBoundary」。

可以說(shuō)，如果Hooks存在如下兩個(gè)生命周期函數(shù)的替代品，就能全面拋棄ClassComponent了：

• getDerivedStateFromError
• componentDidCatch

那為什么還沒(méi)有對(duì)標(biāo)的Hook呢？

今天我們從上述兩個(gè)生命周期函數(shù)的實(shí)現(xiàn)原理，以及要移植到Hook上需要付出的成本來(lái)談?wù)撨@個(gè)問(wèn)題。

ErrorBoundary實(shí)現(xiàn)原理

ErrorBoundary可以捕獲子孫組件中「React工作流程」內(nèi)的錯(cuò)誤。

「React工作流程」指：

• render階段，即「組件render」、「Diff算法」發(fā)生的階段。
• commit階段，即「渲染DOM」、「componentDidMount/Update執(zhí)行」的階段。

這也是為什么「事件回調(diào)中發(fā)生的錯(cuò)誤」無(wú)法被ErrorBoundary捕獲 —— 事件回調(diào)并不屬于「React工作流程」。

如何捕獲錯(cuò)誤

「render階段」的整體執(zhí)行流程如下：

do {
  try {
    // render階段具體的執(zhí)行流程
    workLoop();
    break;
  } catch (thrownValue) {
    handleError(root, thrownValue);
  }
} while (true);

可以發(fā)現(xiàn)，如果「render階段」發(fā)生錯(cuò)誤，會(huì)被捕獲并執(zhí)行handleError方法。

類似的，「commit階段」的整體執(zhí)行流程如下：

try {
  // ...具體執(zhí)行流程
} catch (error) {
  captureCommitPhaseError(current, nearestMountedAncestor, error);
}

如果「commit階段」發(fā)生錯(cuò)誤，會(huì)被捕獲并執(zhí)行captureCommitPhaseError方法。getDerivedStateFromError原理。

捕獲后的錯(cuò)誤如何處理呢？

我們知道，ClassComponent中this.setState第一個(gè)參數(shù)，除了可以接收「新的狀態(tài)」，也能接收「改變狀態(tài)的函數(shù)」作為參數(shù)：

// 可以這樣
this.setState(this.state.num + 1)
// 也可以這樣
this.setState(num => num + 1)

getDerivedStateFromError的實(shí)現(xiàn)，就借助了this.setState中「改變狀態(tài)的函數(shù)」這一特性。

當(dāng)捕獲錯(cuò)誤后，即：

• 對(duì)于「render階段」，handleError執(zhí)行后。
• 對(duì)于「commit階段」，captureCommitPhaseError執(zhí)行后。

會(huì)在ErrorBoundary對(duì)應(yīng)組件中觸發(fā)類似如下更新：

this.setState(
  getDerivedStateFromError.bind(null, error)
)

這就是為什么getDerivedStateFromError要求開(kāi)發(fā)者返回「新的state」— 本質(zhì)來(lái)說(shuō)，他就是觸發(fā)一次新的更新。

componentDidCatch原理

再來(lái)看另一個(gè)ErrorBoundary相關(guān)的生命周期函數(shù)— componentDidCatch。

ClassComponent中this.setState的第二個(gè)參數(shù)，可以接收「回調(diào)函數(shù)」作為參數(shù)：

this.setState(newState, () => {
  // ...回調(diào)
})

當(dāng)觸發(fā)的更新渲染到頁(yè)面后，回調(diào)會(huì)觸發(fā)。

這就是componentDidCatch的實(shí)現(xiàn)原理。

當(dāng)捕獲錯(cuò)誤后，會(huì)在ErrorBoundary對(duì)應(yīng)組件中觸發(fā)類似如下更新：

this.setState(this.state, componentDidCatch.bind(this, error))

處理“未捕獲”的錯(cuò)誤

可以發(fā)現(xiàn)，「React運(yùn)行流程」中的錯(cuò)誤，都已經(jīng)被React自身捕獲了，再交由ErrorBoundary處理。

如果沒(méi)有定義ErrorBoundary，這些「被捕獲的錯(cuò)誤」需要重新拋出，營(yíng)造「錯(cuò)誤未被捕獲的感覺(jué)」。

那這一步在哪里執(zhí)行呢？

與this.setState類似，ReactDOM.render(element, container[, callback])第三個(gè)參數(shù)也能接收「回調(diào)函數(shù)」。

如果開(kāi)發(fā)者沒(méi)有定義ErrorBoundary，那么React最終會(huì)在ReactDOM.render的回調(diào)中拋出錯(cuò)誤。

可以發(fā)現(xiàn)，在ClassComponent中ErrorBoundary的實(shí)現(xiàn)完全依賴了ClassComponent已有的特性。

而Hooks本身并不存在類似this.setState的回調(diào)特性，所以實(shí)現(xiàn)起來(lái)會(huì)比較復(fù)雜。

實(shí)現(xiàn)Hooks中的ErrorBoundary

除了上述談到的阻礙，F(xiàn)unctionComponent與ClassComponent在源碼層面的運(yùn)行流程也有細(xì)節(jié)上的差異，要照搬實(shí)現(xiàn)也有一定難度。

如果一定要實(shí)現(xiàn)，在「最大程度復(fù)用現(xiàn)有基礎(chǔ)設(shè)施」的指導(dǎo)方針下，useErrorBoundary（ErrorBoundary在Hooks中的實(shí)現(xiàn)）的使用方式應(yīng)該類似如下：

function ErrorBoundary({children}: {children: ReactNode}) {
  const [errorMsg, updateError] = useState<Error | null>(null);
  useErrorBoundary((e: Error) => {
    // 捕獲到錯(cuò)誤，觸發(fā)更新
    updateError(e);
  })
  return (
    <div>
      {errorMsg ? '報(bào)錯(cuò)：' + errorMsg.toString() : children}
    </div>
  )
}

其中useErrorBoundary的觸發(fā)方式類似useEffect：

useErrorBoundary((e: Error) => {
  // ...
})
// 類似
useEffect(() => {
  // ...
})

筆者仿照ClassComponent中ErrorBoundary的實(shí)現(xiàn)原理與useEffect的實(shí)現(xiàn)原理，實(shí)現(xiàn)了原生Hooks — useErrorBoundary。

感興趣的朋友可以在useErrorBoundary在線示例[1]體驗(yàn)效果。

總結(jié)

ErrorBoundary在ClassComponent中的實(shí)現(xiàn)使用了this.setState的回調(diào)函數(shù)特性，這使得Hooks中要完全實(shí)現(xiàn)同樣功能，需要額外開(kāi)發(fā)成本。

筆者猜測(cè)，這是沒(méi)有提供對(duì)應(yīng)原生Hooks的原因之一。

參考資料

[1]useErrorBoundary在線示例:https://codesandbox.io/s/angry-mountain-xstgj4?file=/src/App.js。