React+Redux工程目录结构划分

个人习惯使用第三种

 

按角色组织

如果你用MVC框架开发过应用,应该知道MVC框架之下,通常有这样一种代码组织方式:

 
  1. controllers/

  2. todoController.js

  3. filterController.js

  4. models/

  5. todoModel.js

  6. filterModel.js

  7. views/

  8. todo.js

  9. todoItem.js

  10. filter.js

ControllerModelView分别代表三种模块角色。这种组织代码的方式叫做“按角色组织”。

因为MVC的影响深远,一些风格依然影响了前端人员的思维方式,在Redux应用的构建中,就有这种组织方式:

 
  1. reducers/

  2. todoReducer.js

  3. filterReducer.js

  4. actions/

  5. todoAction.js

  6. filterActions.js

  7. components/

  8. todoList.js

  9. todoItem.js

  10. filter.js

  11. containers/

  12. todoListContainer.js

  13. todoItemContainer.js

  14. filterContainer.js

角色如下:

  • reducers 目录包含所有Redux的reducer;
  • actions 目录包含所有action构造函数;
  • components 目录包含所有的展示组件;
  • containers 目录包含所有的容器组件。

这种按角色组织的方式看起来不错,实际非常不利于应用的扩展。当你需要对一个功能进行修改时,要在多个角色目录下切换,当功能模块多了,这种频繁的目录切换即浪费时间也增加了编码厌倦感。

如果说MVC框架下,因为三个角色之间的交叉关系,也只能默默接受,那么在Redux框架下,我们已经有机会实行严格模块化思想。

按功能组织

Redux应用适合于“按功能组织”,也就是把完成同一应用功能的代码放在一个目录下,一个应用功能包含多个角色的代码。Redux中,不同的角色就是reduceractions和视图,而应用功能对应的就是用户界面的交互模块。

Todo应用来说,两个基本的功能就是TodoListFilter,所以按功能组织就是这样子:

 
  1. todoList/

  2. actions.js

  3. actionTypes.js

  4. index.js

  5. reducer.js

  6. views/

  7. components.js

  8. containers.js

  9. filter/

  10. actions.js

  11. actionTypes.js

  12. index.js

  13. reducer.js

  14. views/

  15. components.js

  16. container.js

每个功能模块对应一个目录,分别是todoListfilter,每个目录下包含同样的角色文件:

  • actionTypes.js 定义action类型;
  • actions.js 定义action构造函数;
  • reducer.js 定义这个功能模块如果响应actions.js定义的动作;
  • views 包含功能模块中所有的React组件,包括展示组件和容器组件;
  • index.js 把所有的角色导入,统一导出。

这种组织方式下,当你要修改某个模块时,只要关注对应的目录即可。

按功能组织下的每个模块,都有一个index.js,明确了模块对外的接口:

 
  1. import * as actions from './actions.js';

  2. import reducer from './reducer.js';

  3. import view from './views/container.js';

  4.  
  5. export { actions, reducer, view };

当filter模块依赖todoList模块时,对应的导入代码:

import { actions, reducer, view as TodoList } from '../todoList';

混合方式

大型应用中,下面这种混合方式(既采用类型划分的优势,又添加了功能划分的特点)也是不错的选择。

 
  1. src/ 所有源代码存放的路径

  2. app.js 整个应用的入口

  3. views/ 应用中某个页面的入口文件,一般为路由组件

  4. Home.js 例如,首页的入口就是Home.js

  5. Home.css Home页面对应的样式

  6. HomeRedux.js Home页面中所有与Redux相关的reducer、action creator的汇总,即components/Home/下所有*Redux.js的汇总

  7. components/ 所有应用的组件

  8. Home/ 例如,views/中一个名为Home的view,则在components/中就有一个名为Home的子文件夹

  9. Table.js Home页面中的一个列表组件

  10. Table.css 列表组件对应的样式

  11. TableRedux.js 列表组件的reducer、action creator及action type,整合在一个文件中

  12. Modal.js

  13. Modal.css

  14. ModalRedux.js

  15. shared/ 不归属于任何view的组件,如一些公共组件等

  16. containers/

  17. DevTools.js 配置DevTools

  18. Root.js 一般被app.js依赖,用于根据环境判断是否需要加载DevTools

  19. layouts/ 布局相关的组件及样式,如菜单、侧边栏、header、footer等

  20. redux/ Redux store相关的配置

  21. reducers.js 整个应用中所有reducer的汇总

  22. routes/ 路由相关的配置

  23. utils/ 工具函数、常量等

  24. styles/ 全局公共样式

  25. 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

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值