之前画了一张redux的流程图,可以看看右下角的部分,可以看出来怎么进行优化。
在reducer里面,尽量减少数据的变动
不要做多余、无意义的事
也就是能不改变就不改变。比如不要做下面这种无谓的事情:
function reducer(state,action){ // ....一大堆逻辑代码 return { ...state } }
这个代码虽然在selector中,也可以通过areStatePropsEqual
来判断计算后的state是否发生了改变。
但是如果直接return state;
就可以直接被areStatesEqual
拦截,避免多余的计算和对比。
要做多余的检查
同样,state内部数据,如果数据相同,尽量使用原数据。只针对复杂数据类型(Object
,Array
)。
比如:
function reducer(state,action) { let mayNotChange = state.mayNotChange; // mayNotChange为Array或Object let newState = {...mayNotChange}; // ...一大堆逻辑 return { ...state,mayNotChange: changed ? newState : mayNotChange // 没有发生改变的话,就用原来的对象 } }
很多时候,一般习惯于通过计算,然后直接把生成的newState
赋值给mayNotChange
。
由于众所周知的{} !== {}
的情况,如果能通过简单判断来决定是否可以选择使用原来的对象,那么就可以通过areStatePropsEqual
来进行判断,同样可以避免不必要的计算,更可以避免不必要的渲染。
注: 所说的选择使用原来的对象,是确定数据没有发生改变的时候,使用原对象。并不是说当发生改变的时候,也在原来的对象上面修改最好。在不考虑自定义areStatesEqual和areStatePropsEqual的情况下,如果只在原对象上面进行修改,可能会造成对比的时候,前后两种结果相同,可能造成无法重新渲染的情况
优化equal的四个方法
在connect
的option
中,有四个对比的方法
areStatesEqual
(默认为===
),用来判断redux store
返回的state
是否和之前的相同areOwnPropsEqual
(默认为shallowEqual
),用来判断父组件传入的props
是否和之前的相同areStatePropsEqual
(默认为shallowEqual
),用来判断mapStateToProps
的结果是否和之前的相同areMergedPropsEqual
(默认为shallowEqual
),用来判断最后merge合并的最终结果是否和之前的相同
可以通过自己的需求对着四个方法进行优化。
比如一个redux
的state
是这个样子:
state = { pageA: {...},pageB: {...},number: 2 }
而在pageA里面只需要pageA
和number
,那么就可以通过areStatesEqual
来进行对比:
function areStatesEqual(prev,current){ return prev.number === current.number && isEqual(prev.pageA,current.pageA); }
或者针对复杂结构数据的情况,进行特殊处理,比如深度对比
function areStatePropsEqual(prev,current){ return deepEqual(prev,current); }
这些优化都可以减少不必要的计算和重渲染。
shouldComponentUpdate
多余提一句,在使用shouldComponentUpdate
的时候,要谨慎使用。这个方法就是利用shouldComponentUpdate的消耗来换取render的消耗。
当某些小的、调用的次数少的component,就没有必要添加shouldComponentUpdate检查。
当组件够大,够复杂,可以考虑使用这个方法来减少re-render的消耗。当然,还是需要考虑用这个方法的消耗和diff&render的消耗比起来哪个更划算。
先想到这么多,等想到了其他的再添加上来。