zoukankan      html  css  js  c++  java
  • 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

  • 相关阅读:

    2018.10.18 常用API部分测试题
    2018.10.18课堂笔记HashMap之前
    JavaScript 的 this 原理
    vue h5转换uni-app
    Vue.js 3.0 新特性预览
    ES6模块与CommonJS的区别
    同源策略和跨域问题
    一口气了解 babel
    媒体查询,移动端常见布局以及其他
  • 原文地址:https://www.cnblogs.com/SyMind/p/10228359.html
Copyright © 2011-2022 走看看