1

之前画了一张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的四个方法

connectoption中,有四个对比的方法

  1. areStatesEqual(默认为===),用来判断redux store返回的state是否和之前的相同

  2. areOwnPropsEqual(默认为shallowEqual),用来判断父组件传入的props是否和之前的相同

  3. areStatePropsEqual(默认为shallowEqual),用来判断mapStateToProps的结果是否和之前的相同

  4. areMergedPropsEqual(默认为shallowEqual),用来判断最后merge合并的最终结果是否和之前的相同

可以通过自己的需求对着四个方法进行优化。


比如一个reduxstate是这个样子:

  state = {
    pageA: {...},
    pageB: {...},
    number: 2
  }

而在pageA里面只需要pageAnumber,那么就可以通过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的消耗比起来哪个更划算。



先想到这么多,等想到了其他的再添加上来。


Clark
3.4k 声望82 粉丝

[链接]