大家好,我卡颂。
稍微深入了解过useState
的同学都知道 —— useState
其实是预置了reducer
的useReducer
。具体来讲,他预置的reducer
实现如下:
function basicStateReducer(state, action) {
// $FlowFixMe: Flow doesn't like mixed types
return typeof action === 'function' ? action(state) : action;
}
那按理来说,useState
与useReducer
性能应该完全一致才对。但实际上,他们的性能并不一样。本文就来聊聊他们的细微差别。
欢迎加入人类高质量前端交流群,带飞
一个严重的bug
在v18
之前,特定场景下,useReducer
存在一个严重的bug
。假设我们要挂载如下App
组件:
bug复现地址
function App() {
const [disabled, setDisabled] = React.useState(false);
return (
<>
<button onClick={() => setDisabled((prev) => !prev)}>Disable</button>
<div>{`Disabled? ${disabled}`}</div>
<CounterReducer disabled={disabled} />
</>
);
}
通过点击按钮,可以切换disabled
状态,并将disabled
作为props
传递给CounterReducer
组件。
CounterReducer
组件的实现如下:
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
状态初始为0,当disabled props
为true
时,点击reducer + 1按钮后count
不会变化。
当disabled props
为false
时,点击reducer + 1按钮后count
会加1。
现在问题来了,当disabled props
为true
时(此时count
为0),我们点击reducer + 1按钮5次,然后再点击Disable按钮(disabled props
会变为false
),此时count
为多少呢?
按照代码逻辑,改变disabled
对count
不会造成影响,所以他应该保持原始状态不变(即为0)。
但在v18
之前,他会变成5。
但是,如果我们用useState
实现同样逻辑的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
的实现在特殊场景下是有bug
的(v18之前)。
bug是如何产生的
产生这个bug
的原因在于React
内部的一种被称为eager state
的性能优化策略。
简单的说,对于类似如下这样的,即使多次触发更新,但状态的最终结果不变的情况(在如下例子中count
始终为0):
function App() {
const [count, dispatch] = useState(0);
return <button onClick={() => dispatch(0)}>点击</button>;
}
App
组件是没有必要render
的。这就省去了render
的性能开销。
要命中eager state
,有个严格的前提 —— 状态更新前后不变。
我们知道,React
中有两种更新状态的方式:
- 传递新的状态
// 定义状态
const [count, dispatch] = useState(0);
// 更新状态
dispatch(100)
- 传递更新状态的函数
// 定义状态
const [count, dispatch] = useState(0);
// 更新状态
dispatch(oldState => oldState + 100)
那么,对于方式1,要保证状态不变很简单,只需要全等比较变化前后的状态,如果他们一致就能进入eager state
策略。
对于方式2,就略微复杂点,需要同时满足2个条件:
- 状态更新函数本身不变
- 通过状态更新函数计算出的新状态也不变
比如,下述代码就同时满足2个条件,但如果将change
放到App
内就不满足条件1(App
组件每次render
时都会创建新的change
函数):
// 状态更新函数本身不变
function change(oldState) {
// 新状态也不变
return oldState;
}
function App() {
const [count, dispatch] = useState(0);
// 状态更新函数每次render都会变化
// function change(oldState) {
// 新状态不变
// return oldState;
// }
return <button onClick={() => dispatch(change)}>点击</button>;
}
类似的情况,在useState
的实现中,虽然他是预置了reducer
的useReducer
,但他预置的reducer
的引用是不变的,所以用他实现的文章开篇的例子可以命中优化策略。
useReducer
在特定场景下的bug
就与此相关。并不是说bug
产生的原因是useReducer
一定没命中优化策略,而是说相比于useState
,他命中优化策略很不稳定。
v18之后的改变
既然bug
来源于不稳定的性能优化策略,在没有完美的解决方案之前,React
是如何在v18
中修复这个bug
的呢?
答案是 —— 移除useReducer
的eager state
策略。也就是说,在任何情况下,useReducer
都不再有useState
存在的这个性能优化策略了。
这就导致在特定场景下,useReducer
的性能弱于useState
。
比如在这个v18在线示例中,同样的逻辑用useState
实现,不会有冗余的render
,而useReducer
会有。
总结
在考虑性能优化时,如果useState
与useReducer
都能满足需要,或许useState
是更好的选择。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。