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

模块化应用的要点

代码文件的组织方式

状态数的设计

开发辅助工具

一、模块化应用的要点

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

代码文件的组织结构

确定模块的边界

store的状态树设计

代码文件的组织方式：

按功能组织

Redux应用适用于按功能组织划分，即把完成同一应用功能的代码放在一个目录下，一个应用功能包含多个角色的代码。在Redux中，不同的角色就是reducer、actions和视图，而应用功能对应的就是用户界面上的交互模块。

拿Todo应用为例子，这个应用的两个基本功能就是TodoList和Filter，所以代码就这样组织，文件目录列表如下：

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

每个基本功能对应的其实就是一个功能模块，每个功能模块对应一个目录，每个目录下包含同样名字的角色文件。

actionTypes.js定义action类型；

actions.js定义action构造函数，决定了这个功能模块可以接受的动作；

reducer.js定义这个功能模块如何响应actions.js中定义的动作；

views目录，包含这个功能模块中所有的React组件，包括傻瓜组件和容器组件；

index.js这个文件把所有的角色导入，然后统一导出

在这种组织方式下，当你要修改某个功能模块的代码的时候，只要关注对应的目录就行了，所有需要修改的代码文件都能在这个目录下找到。

模块接口

每个功能模块下都有一个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 开发辅助工具

reactreduxReact

0