目錄

• 引言
• 一個嚴重的bug
• bug是如何產(chǎn)生的
• v18之后的改變
• 總結(jié)

引言

稍微深入了解過useState的同學都知道 —— useState其實是預置了reducer的useReducer。具體來講，他預置的reducer實現(xiàn)如下：

function basicStateReducer(state, action) {  // $FlowFixMe: Flow doesn"t like mixed types  return typeof action === "function" ? action(state) : action;}

那按理來說，useState與useReducer性能應該完全一致才對。但實際上，他們的性能并不一樣。本文就來聊聊他們的細微差別。

一個嚴重的bug

在v18之前，特定場景下，useReducer存在一個嚴重的bug。假設(shè)我們要掛載如下App組件：

function App() {  const [disabled, setDisabled] = React.useState(false);  return (    <>      <button onClick={() => setDisabled((prev) => !prev)}>Disable</button>      <div>{`Disabled? ${disabled}`}</div>      <CounterReducer disabled={disabled} />    </>  );}

通過點擊按鈕，可以切換disabled狀態(tài)，并將disabled作為props傳遞給CounterReducer組件。

CounterReducer組件的實現(xiàn)如下：

function CounterReducer({ disabled }) {  const [count, dispatch] = useReducer((state) => {    if (disabled) {      return state;    }    return state + 1;  }, 0);  return (    <>      <button onClick={dispatch}>reducer + 1</button>      <div>{`Count ${count}`}</div>    </>  );}

count狀態(tài)初始為0，當disabled props為true時，點擊reducer + 1按鈕后count不會變化。

當disabled props為false時，點擊reducer + 1按鈕后count會加1。

現(xiàn)在問題來了，當disabled props為true時（此時count為0），我們點擊reducer + 1按鈕5次，然后再點擊Disable按鈕（disabled props會變?yōu)?code>false），此時count為多少呢？

按照代碼邏輯，改變disabled對count不會造成影響，所以他應該保持原始狀態(tài)不變（即為0）。

但在v18之前，他會變成5。

但是，如果我們用useState實現(xiàn)同樣邏輯的useReducer：

function CounterState({ disabled }) {  const [count, dispatch] = useState(0);  function dispatchAction() {    dispatch((state) => {      if (disabled) {return state;      }      return state + 1;    });  }  return (    <>      <button onClick={dispatchAction}>state + 1</button>      <div>{`Count ${count}`}</div>    </>  );}

就能取得符合預期的效果。

所以說，useReducer的實現(xiàn)在特殊場景下是有bug的（v18之前）。

bug是如何產(chǎn)生的

產(chǎn)生這個bug的原因在于React內(nèi)部的一種被稱為eager state的性能優(yōu)化策略。

簡單的說，對于類似如下這樣的，即使多次觸發(fā)更新，但狀態(tài)的最終結(jié)果不變的情況（在如下例子中count始終為0）：

function App() {  const [count, dispatch] = useState(0);  return <button onClick={() => dispatch(0)}>點擊</button>;}

App組件是沒有必要render的。這就省去了render的性能開銷。

要命中eager state，有個嚴格的前提 —— 狀態(tài)更新前后不變。

我們知道，React中有兩種更新狀態(tài)的方式：

• 傳遞新的狀態(tài)

// 定義狀態(tài)const [count, dispatch] = useState(0);// 更新狀態(tài)dispatch(100)

• 傳遞更新狀態(tài)的函數(shù)

// 定義狀態(tài)const [count, dispatch] = useState(0);// 更新狀態(tài)dispatch(oldState => oldState + 100)

那么，對于方式1，要保證狀態(tài)不變很簡單，只需要全等比較變化前后的狀態(tài)，如果他們一致就能進入eager state策略。

對于方式2，就略微復雜點，需要同時滿足2個條件：

• 狀態(tài)更新函數(shù)本身不變
• 通過狀態(tài)更新函數(shù)計算出的新狀態(tài)也不變

比如，下述代碼就同時滿足2個條件，但如果將change放到App內(nèi)就不滿足條件1（App組件每次render時都會創(chuàng)建新的change函數(shù)）：

// 狀態(tài)更新函數(shù)本身不變function change(oldState) {  // 新狀態(tài)也不變  return oldState;}function App() {  const [count, dispatch] = useState(0);  // 狀態(tài)更新函數(shù)每次render都會變化  // function change(oldState) {     // 新狀態(tài)不變     // return oldState;  // }  return <button onClick={() => dispatch(change)}>點擊</button>;}

類似的情況，在useState的實現(xiàn)中，雖然他是預置了reducer的useReducer，但他預置的reducer的引用是不變的，所以用他實現(xiàn)的文章開篇的例子可以命中優(yōu)化策略。

useReducer在特定場景下的bug就與此相關(guān)。并不是說bug產(chǎn)生的原因是useReducer一定沒命中優(yōu)化策略，而是說相比于useState，他命中優(yōu)化策略很不穩(wěn)定。

v18之后的改變

既然bug來源于不穩(wěn)定的性能優(yōu)化策略，在沒有完美的解決方案之前，React是如何在v18中修復這個bug的呢？

答案是 —— 移除useReducer的eager state策略。也就是說，在任何情況下，useReducer都不再有useState存在的這個性能優(yōu)化策略了。

這就導致在特定場景下，useReducer的性能弱于useState。

比如在v18在線示例中，同樣的邏輯用useState實現(xiàn)，不會有冗余的render，而useReducer會有。

總結(jié)

在考慮性能優(yōu)化時，如果useState與useReducer都能滿足需要，或許useState是更好的選擇。

以上就是useState與useReducer性能區(qū)別圖文示例詳解的詳細內(nèi)容，更多關(guān)于useState useReducer性能區(qū)別的資料請關(guān)注其它相關(guān)文章！