React+Redux工程目录结构划分

最新推荐文章于 2025-10-14 15:05:22 发布

转载最新推荐文章于 2025-10-14 15:05:22 发布 · 1.3k 阅读

文章标签：

#react

React点滴知识专栏收录该内容

48 篇文章

订阅专栏

本文介绍了React应用的三种代码组织方式。按角色组织虽常见但不利于应用扩展；按功能组织将完成同一功能的代码放于一个目录，便于修改；大型应用可采用混合方式，结合类型与功能划分优势，还提到Redux应用文件组织的优化。

个人习惯使用第三种

按角色组织

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

controllers/
todoController.js
filterController.js
models/
todoModel.js
filterModel.js
views/
todo.js
todoItem.js
filter.js

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

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

reducers/
todoReducer.js
filterReducer.js
actions/
todoAction.js
filterActions.js
components/
todoList.js
todoItem.js
filter.js
containers/
todoListContainer.js
todoItemContainer.js
filterContainer.js

角色如下：

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

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

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

按功能组织

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