若是你用MVC框架开发过应用,应该知道MVC
框架之下,一般有这样一种代码组织方式:css
controllers/ todoController.js filterController.js models/ todoModel.js filterModel.js views/ todo.js todoItem.js filter.js
Controller
、Model
、View
分别表明三种模块角色。这种组织代码的方式叫作“按角色组织”。前端
由于MVC
的影响深远,一些风格依然影响了前端人员的思惟方式,在Redux应用的构建中,就有这种组织方式:git
reducers/ todoReducer.js filterReducer.js actions/ todoAction.js filterActions.js components/ todoList.js todoItem.js filter.js containers/ todoListContainer.js todoItemContainer.js filterContainer.js
角色以下:github
reducers
目录包含全部Redux的reducer;actions
目录包含全部action构造函数;components
目录包含全部的展现组件;containers
目录包含全部的容器组件。这种按角色组织的方式看起来不错,实际很是不利于应用的扩展。当你须要对一个功能进行修改时,要在多个角色目录下切换,当功能模块多了,这种频繁的目录切换即浪费时间也增长了编码厌倦感。redux
若是说MVC
框架下,由于三个角色之间的交叉关系,也只能默默接受,那么在Redux
框架下,咱们已经有机会实行严格模块化思想。app
Redux
应用适合于“按功能组织”,也就是把完成同一应用功能的代码放在一个目录下,一个应用功能包含多个角色的代码。Redux
中,不一样的角色就是reducer
、actions
和视图,而应用功能对应的就是用户界面的交互模块。框架
拿Todo
应用来讲,两个基本的功能就是TodoList
和Filter
,因此按功能组织就是这样子:模块化
todoList/ actions.js actionTypes.js index.js reducer.js views/ components.js containers.js filter/ actions.js actionTypes.js index.js reducer.js views/ components.js container.js
每一个功能模块对应一个目录,分别是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模块时,对应的导入代码:
import { actions, reducer, view as TodoList } from '../todoList';
大型应用中,下面这种混合方式(既采用类型划分的优点,又添加了功能划分的特色)也是不错的选择。
src/ 全部源代码存放的路径 app.js 整个应用的入口 views/ 应用中某个页面的入口文件,通常为路由组件 Home.js 例如,首页的入口就是Home.js Home.css Home页面对应的样式 HomeRedux.js Home页面中全部与Redux相关的reducer、action creator的汇总,即components/Home/下全部*Redux.js的汇总 components/ 全部应用的组件 Home/ 例如,views/中一个名为Home的view,则在components/中就有一个名为Home的子文件夹 Table.js Home页面中的一个列表组件 Table.css 列表组件对应的样式 TableRedux.js 列表组件的reducer、action creator及action type,整合在一个文件中 Modal.js Modal.css ModalRedux.js shared/ 不归属于任何view的组件,如一些公共组件等 containers/ DevTools.js 配置DevTools Root.js 通常被app.js依赖,用于根据环境判断是否须要加载DevTools layouts/ 布局相关的组件及样式,如菜单、侧边栏、header、footer等 redux/ Redux store相关的配置 reducers.js 整个应用中全部reducer的汇总 routes/ 路由相关的配置 utils/ 工具函数、常量等 styles/ 全局公共样式 app.css 应用主样式表
基本上,咱们只须要关注的就是views/和components/这两个目录,它们也是存放绝大多数业务代码的地方。
在views/目录中,存放的是每一个路由的入口页,如首页(Home)、详情页(Detail)、管理后台页(Admin)等。而每一个入口都会有三个文件:.js是入口的组件,.css是对应组件的样式,而*Redux.js是components/Home/目录下全部reducer和action的聚合。
在components/Home/目录里,是当前路由对应的页面(Home)须要的全部内容------components、actions、reducers、样式等。
什么是*Redux.js?实际上,按照Redux应用的通常目录结构划分方式,应该分别有reducers、action creator和constants文件夹。可是在实际应用中,咱们发现这样的划分方式略显繁琐,添加一个组件须要至少新建4个文件。同时对于业务应用来讲,reducers等于Redux相关的文件并不太可能被其余地方复用,所以放在一个文件里组织并管理是更好的选择。目前在Redux社区中也存在一个相似的规范。Ducks modular redux