目录
  1. 1. 深入浅出React和Redux学习笔记(四)
    1. 1.1. 模块化React和Redux应用
    2. 1.2. 1.模块化应用要点
    3. 1.3. 2.代码文件的组织方式
      1. 1.3.1. 2.1按角色组织
      2. 1.3.2. 2.2按功能组织
    4. 1.4. 3.模块接口
    5. 1.5. 4.状态树的设计
      1. 1.5.1. 4.1一个节点只属于一个模块
      2. 1.5.2. 4.2避免冗余数据
      3. 1.5.3. 4.3树形结构扁平
    6. 1.6. 5.Todo应用实例
    7. 1.7. 6.开发辅助工具
      1. 1.7.1. 6.1Chrome扩展包
      2. 1.7.2. 6.2redux-immutable-sate-invariant辅助包
深入浅出React和Redux学习笔记(四)

深入浅出React和Redux学习笔记(四)

模块化React和Redux应用

创建一个复杂的应用该如何操作?

  1. 模块化应用的要点;
  2. 代码文件的组织方式;
  3. 状态树的设计;
  4. 开发辅助工具;

1.模块化应用要点

React负责视图,Redux管理状态。

开始一个新的应用应该考虑的事情:

  1. 代码文件的组织结构;

  2. 确认模块的边界;

  3. Store的状态树的设计;

2.代码文件的组织方式

2.1按角色组织

按角色组织(Organized by Roles):在MVC中,应用代码分为Controller、Model、View,分别代表三种不同角色,把对应角色的代码放入对应目录中的组织代码方式。

Redux按角色组织代码文件目录:

  1. reducer:所有Redux的reducer;
  2. actions:所有action的构造函数;
  3. components:所有的傻瓜组件;
  4. containers:所有的容器组件;

2.2按功能组织

每个基本功能对应一个功能模块,每个功能模块对应一个目录。

3.模块接口

“在最理想的情况下,我们应该通过增加代码就能增加系统的功能,而不是对现有代码的修改来增加代码”

不同功能模块之间的依赖关系应该简单而清晰,即保持模块的低耦合性;一个模块应该把自己的功能封装的很好,让外界不要太依赖与自己的内部结构,不会因内部结构的变化而导致外部模块的功能,即高内聚性。

4.状态树的设计

状态树的设计的原则:

  1. 一个模块控制一个状态节点;
  2. 避免冗余数据;
  3. 树形结构扁平;

4.1一个节点只属于一个模块

Store上的每个state只能通过reducer来修改,每个模块都有机会导出一个自己的reducer。

reducer之间的状态树上的修改权是互斥的,不可能让两个reducer都可以修改同一个状态树上的节点。

4.2避免冗余数据

冗余数据是一致性的大敌,如果在Store上存储冗余数据,那么维持不同部分数据一致性就是个大问题。

相对于性能问题,数据一致性更加重要。

4.3树形结构扁平

如果树形结构层次很深,往往意味着树形很复杂,一个很复杂的状态树是很难管理的。

从代码的角度看,深层次树形状态结构会让代码很冗长。

5.Todo应用实例

6.开发辅助工具

6.1Chrome扩展包

React和Redux开发的三个Chrome扩展包:

  1. React Devtools:检视React组件的树形结构;
  2. Redux Devtools:检视Redux数据流,可以将Store状态跳跃到任何一个历史状态;
  3. React Perf:可以发现React组件的渲染性能问题;

6.2redux-immutable-sate-invariant辅助包

redux-immutable-sate-invariant包:提供一个Redux的中间件,能让Redux在每次派发动作后做一个检查。

中间件:增强Redux和Store实例功能的一种方法。

文章作者: BleakNight
文章链接: https://bleaknight95.github.io/2019/12/12/%E6%B7%B1%E5%85%A5%E6%B5%85%E5%87%BAReact%E5%92%8CRedux%E5%AD%A6%E4%B9%A0%E7%AC%94%E8%AE%B0%EF%BC%88%E5%9B%9B%EF%BC%89/
版权声明: 本博客所有文章除特别声明外,均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来自 BleakNight's Blog
打赏
  • 微信
  • 支付寶

评论