创建一个复杂一点的应用应该如何做：
- 模块化应用的要点
- 代码文件的组织方式
- 状态数的设计
- 开发辅助工具
一、模块化应用的要点 1.构建一个应用的基础要做如下3件事情：
- 代码文件的组织结构
- 确定模块的边界
- store的状态树设计
- 代码文件的组织方式：
按功能组织
Redux应用适用于按功能组织划分，即把完成同一应用功能的代码放在一个目录下，一个应用功能包含多个角色的代码。在Redux中，不同的角色就是reducer、actions和视图，而应用功能对应的就是用户界面上的交互模块。
拿Todo应用为例子，这个应用的两个基本功能就是TodoList和Filter，所以代码就这样组织，文件目录列表如下：
每个基本功能对应的其实就是一个功能模块，每个功能模块对应一个目录，每个目录下包含同样名字的角色文件。
- 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 开发辅助工具
