React总结篇之四_模块化React和Redux应用

创建一个复杂一点的应用应该如何做：

• 模块化应用的要点
• 代码文件的组织方式
• 状态数的设计
• 开发辅助工具

一、模块化应用的要点
1.构建一个应用的基础要做如下3件事情：

• 代码文件的组织结构
• 确定模块的边界
• store的状态树设计

2. 代码文件的组织方式：
   按功能组织
   Redux应用适用于按功能组织划分，即把完成同一应用功能的代码放在一个目录下，一个应用功能包含多个角色的代码。在Redux中，不同的角色就是reducer、actions和视图，而应用功能对应的就是用户界面上的交互模块。
   拿Todo应用为例子，这个应用的两个基本功能就是TodoList和Filter，所以代码就这样组织，文件目录列表如下：
   
   每个基本功能对应的其实就是一个功能模块，每个功能模块对应一个目录，每个目录下包含同样名字的角色文件。

   • actionTypes.js定义action类型；
   • actions.js定义action构造函数，决定了这个功能模块可以接受的动作；
   • reducer.js定义这个功能模块如何响应actions.js中定义的动作；
   • views目录，包含这个功能模块中所有的React组件，包括傻瓜组件和容器组件；
   • index.js这个文件把所有的角色导入，然后统一导出
     在这种组织方式下，当你要修改某个功能模块的代码的时候，只要关注对应的目录就行了，所有需要修改的代码文件都能在这个目录下找到。
3. 模块接口
   每个功能模块下都有一个index.js文件，这个文件就是我们的模块接口。
   举例如下：
   import * as actions from './actions.js'
   import reducer from './reducer.js'
   import view from './views/container.js'
   export {actions,reducer,view}
   如果filter中的组件想要使用todoList中的功能，应该导入todoList这个目录。因为导入这个目录的时候，默认导入的就是这个目录下的index.js文件，就是这个模块想要公开出来的接口。

4.状态树的设计
状态树的设计建议遵循以下几个原则：

• 一个模块控制一个状态节点
• 避免冗余数据
• 树形结构扁平

4.1 一个状态节点只属于一个模块
在Redux应用中，store上的每一个state都只能通过reducer来更改，而我们每个模块都有机会导出一个自己的reducer，这个导出的reducer只能最多更改Redux的状态树上一个节点下的数据，因为reducer之间对状态树上的修改权是互斥的，不能让两个reducer都可以修改同一个状态树上的节点。比如，如果A模块的reducer负责修改状态树a字段下的数据，那么另一个模块B的reducer就不可能有机会修改a字段下的数据。这里指的是‘修改权’，不是‘读取权’（读取权对任何模块都是开放的）。

4.2 避免冗余数据
在Redux的Store中，一定要避免数据的冗余，因为这可能会导致数据不一致的问题。

4.3 树形结构扁平
在设计Redux Store的状态树时，要尽量保持树形结构的扁平（树形结构不要深）。

4.4 不使用ref

4.5 开发辅助工具