码迷,mamicode.com
首页 > 其他好文 > 详细

Redux在处理庞大Store并频繁进行更新操作时的性能

时间:2019-01-06 13:35:54      阅读:197      评论:0      收藏:0      [点我收藏+]

标签:一个   分解   blank   https   redux   pre   str   其他   get   

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并频繁进行更新操作时的性能

标签:一个   分解   blank   https   redux   pre   str   其他   get   

原文地址:https://www.cnblogs.com/SyMind/p/10228359.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!