React + Redux的模块组织方式

React + Redux 是React生态中使用最频繁的技术栈，关于如何组织React+Redux的项目结构有如下几种：

 

按照类型

 

这里的类型指的是一个文件在项目中充当的角色类型，即这个文件是一个component，还是一个container，或者是一个reducer等，充当component、container、action、reducer等不同角色的文件，分别放在不同的文件夹下，这也是Redux官网示例所采用的项目结构。这种结构如下所示：

 

actions/
  a.js
  b.js
components/
  a1.js
  a2.js
  b1.js
constainers/
  a.js
  b.js
reducers/
  a.js
  b.js
index.js

 

缺陷
使用这种结构组织项目，每当增加一个新功能时，需要在containers和components文件夹下增加这个功能需要的组件，还需要在actions和reducers文件夹下，分别添加Redux管理这个功能使用到的action和reducer。

 

按照功能

 

一个功能模块对应一个文件夹，这个功能所用到的container、component、action、reducer等文件，都存放在这个文件夹下。如下所示：

 

feature1/
  components/
  actions.js
  container.js
  index.js
  reducer.js
feature2/
  components/
  actions.js
  container.js
  index.js
  reducer.js
index.js
rootReducer.js

 

优势
一个功能中使用到的组件、状态和行为都在同一个文件夹下，方便开发，易于功能的扩展。
缺陷
Redux会将整个应用的状态作为一个store来管理，不同的功能模块之间可以共享store中的部分状态（项目越复杂，这种场景就会越多），于是当你在feature1的container中dispatch一个action，很可能会影响feature2的状态，因为feature1和feature2共享了部分状态，会响应相同的action。不同模块间的功能会被耦合到一起。

 

Ducks

 

将相关联的reducer、action types和action写到一个文件里。本质上是以应用的状态作为模块的划分依据，而不是以界面功能作为划分模块的依据。如下所示：

 

// reducer
export default function reducer(state = {}, action = {}) {
  switch (action.type) {
    // do reducer stuff
    default: return state;
  }
}
// Action Creators
export function creators1() {
  return { type: LOAD };
}

export function creators2() {
  return { type: CREATE };
}

 

整体的目录结构：

 

components/  (应用级别的通用组件)
containers/  
  feature1/
    components/  (功能拆分出的专用组件)
    feature1.js  (容器组件)
    index.js     (feature1对外暴露的接口)
redux/
  index.js (combineReducers)
  module1.js (reducer, action types, actions creators)
  module2.js (reducer, action types, actions creators)
index.js

 

优势
管理相同状态的依赖都在同一个文件中，不管哪个容器组件需要使用这部分状态，只需要在这个组件中引入这个状态对应的文件即可。