Redux在处理庞大Store并频繁进行更新操作时的性能
Posted symind
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Redux在处理庞大Store并频繁进行更新操作时的性能相关的知识,希望对你有一定的参考价值。
Q:当你拥有一个相当大的 SPA 拥有许多状态,因为有很多页面,模块,子模块和许多元素。所有子状态都关联 App 中不同的关注点,子状态由它们自己的 reducer 处理。但是当进行非常频繁的更新操作,所有的 reducer 都将被调用。
当拥有一个如下的 store:
store: {
subStore1: {
subSubstore1: {}
...
subSubstore10: {}
},
subStore2: {
subSubstore1: {}
...
subSubstore10: {}
}
...
subStore10: {
subSubstore1: {}
...
subSubstore10: {}
}
}
dispatch 一个更新 substore2: { subStore6 } 的 action。
为什么不简单地复制指针 substore1、substore3、... substore9,而现在是调用其他子 store 的 reducer?
A:可以使用 redux-ignore https://github.com/omnidan/redux-ignore。
Redux Store 中只有一个 reducer 函数。你可以分解该函数,并根据你的需求来权衡便利、速度或其他因素。combineReducers 是处理此问题的常用方法,但并不是必需的。
如何处理那些已订阅状态变化的组件?
使用 react-redux。由 React-Redux 的 connect() 函数生成的包装组件会进行多次检查,以尽量减少实际组件重渲染(re-render)。这包括 shouldComponentUpdate 的默认实现,并对进入组件的 props 进行浅检查(包括从 mapStateToProps 返回的内容)。所以一般情况下,被 connect 的组件只有在状态值发生变化时才会重渲染。
参考:https://github.com/reduxjs/redux/issues/1303
以上是关于Redux在处理庞大Store并频繁进行更新操作时的性能的主要内容,如果未能解决你的问题,请参考以下文章
Redux reducer 不更新 store/redux-promise 不解决