建站
咨詢
售后
建站咨詢
新聞中心
大家好，我卡頌。
創(chuàng)新互聯(lián)建站總部坐落于成都市區(qū)，致力網(wǎng)站建設(shè)服務(wù)有網(wǎng)站設(shè)計、成都網(wǎng)站建設(shè)、網(wǎng)絡(luò)營銷策劃、網(wǎng)頁設(shè)計、網(wǎng)站維護、公眾號搭建、小程序制作、軟件開發(fā)等為企業(yè)提供一整套的信息化建設(shè)解決方案。創(chuàng)造真正意義上的網(wǎng)站建設(shè)，為互聯(lián)網(wǎng)品牌在互動行銷領(lǐng)域創(chuàng)造價值而不懈努力！
稍微深入了解過useState的同學(xué)都知道 —— useState其實是預(yù)置了reducer的useReducer。具體來講，他預(yù)置的reducer實現(xiàn)如下：
function basicStateReducer(state, action) {
// $FlowFixMe: Flow doesn't like mixed types
return typeof action === 'function' ? action(state) : action;
}那按理來說，useState與useReducer性能應(yīng)該完全一致才對。但實際上，他們的性能并不一樣。本文就來聊聊他們的細微差別。
一個嚴重的bug
在v18之前，特定場景下，useReducer存在一個嚴重的bug。假設(shè)我們要掛載如下App組件：
bug復(fù)現(xiàn)地址[1]
function App() {
const [disabled, setDisabled] = React.useState(false);
return (
<>
{`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 (
<>
{`Count ${count}`}
);
}count?狀態(tài)初始為0，當(dāng)disabled props為true?時，點擊「reducer + 1按鈕」后count不會變化。
disabled為true時，多次點擊后count仍顯示0
當(dāng)disabled props為false?時，點擊「reducer + 1按鈕」后count會加1。
disabled為false時，點擊后count加1
現(xiàn)在問題來了，當(dāng)disabled props為true?時（此時count?為0），我們點擊「reducer + 1按鈕」5次，然后再點擊「Disable按鈕」（disabled props?會變?yōu)閒alse?），此時count為多少呢？
按照代碼邏輯，改變disabled對count不會造成影響，所以他應(yīng)該保持原始狀態(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 (
<>
{`Count ${count}`}
);
}就能取得符合預(yù)期的效果。
所以說，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 ;
}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，就略微復(fù)雜點，需要同時滿足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 ;
}
類似的情況，在useState的實現(xiàn)中，雖然他是預(yù)置了reducer的useReducer，但他預(yù)置的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?中修復(fù)這個bug的呢？
答案是 —— 移除useReducer?的eager state?策略。也就是說，在任何情況下，useReducer?都不再有useState存在的這個性能優(yōu)化策略了。
這就導(dǎo)致在特定場景下，useReducer?的性能弱于useState。
比如在這個v18在線示例[2]中，同樣的邏輯用useState?實現(xiàn)，不會有冗余的render?，而useReducer會有。
總結(jié)
在考慮性能優(yōu)化時，如果useState與useReducer都能滿足需要，或許useState是更好的選擇。
參考資料
[1]bug復(fù)現(xiàn)地址:https://codesandbox.io/s/vigorous-dhawan-mqv463。
[2]v18在線示例:https://codesandbox.io/s/blazing-cdn-pzcpz6?file=/src/App.js:509-519。
當(dāng)前文章：UseState與UseReducer性能居然有區(qū)別？
鏈接地址：http://m.5511xx.com/article/cojijoe.html
