javascript - 避免在 Redux 中使用多个 reducer 监听相同操作的导入顺序/cirulcar 依赖错误

Question

我一直在使用似乎很常见的“模块”模式开发 Redux 项目，其中负责单个状态片段的 Action 集、 Action 创建者和 Action 处理程序被组合在一个文件中, 并且从这些文件导出的 reducer 被 combineReducers 合并到一个单一的根 reducer 中。

我一直在使用这种模式并取得了一些成功，但是当我尝试让模块监听其他模块导出的 Action 时，我遇到了一些非常微妙和烦人的错误。

我第一次遇到这个问题，是模块A从模块B导入一个action，模块B从模块A导入一个action，造成循环依赖。很好，可以理解，我可以忍受处理此类情况。

但我也遇到过这样的情况，即简单地从模块 A 中导入一个 Action 到模块 B 会导致该 Action 未定义——我假设基于模块被 combineReducers 导入或消化的顺序，尽管我没有不知道究竟是如何发生的(即使在 rootReducer 文件中模块 A 在模块 B 之前导入时，它似乎有时也会发生)。

所以我的问题是:在多个 reducer 中监听相同的 Action 被认为是一种好的模式，还是应该避免的事情？这似乎是 Redux 做事方式所鼓励的，但我可能遗漏了一些东西。

举一个人为的例子，假设我想在我的应用程序中保留某些操作的运行日志。所以我有一个“日志”模块，它可以监听所需的操作并根据需要更新其状态片段。

假设我有一个用户模块，它开始于:

export const ADD_USER = 'ADD_USER';

export function addUser (user) {
  return {
    type: ADD_USER,
    user: user
  }
};

等等

然后，如果我想在添加新用户时记录日志，我可能会这样做:

   import { ADD_USER } from './users';

   const ACTION_HANDLERS = {
    [ADD_USER]: (state, action) => {
       return [
         ...state,
         'Added user: ' + action.user.name
       ];
     }
   }
   const initialState = []
   export default function logReducer (state = initialState, action) {
      const handler = ACTION_HANDLERS[action.type]
      return handler ? handler(state, action) : state
   }

大多数情况下，这种方法效果很好。但有时 ADD_USER 在导入时未定义，因此操作处理程序将(悄悄地)错过该操作。很烦人!

如果这确实是要走的路，我应该如何避免这些错误？显而易见的解决方案似乎是将 Action 常量放在一个单独的 actions.js 文件中，该文件在所有模块之前导入，但这似乎违背了模块化的要点。另一种选择是像这样编写操作处理程序:

ADD_USER: (state, action) => {}

当收听“外部” Action 时。但是为什么要将它们定义并导出为常量呢？

Answer 1

是的，Redux 绝对鼓励让多个 reducer 响应相同的操作。这就是为什么典型的基本 Redux 文件结构确实会有单独的文件用于操作常量 - 它们可以由多个单独的 reducer 文件导入，也可能由单独的操作创建者文件导入。

“鸭子”或“模块”结构有些流行，当然也是组织代码的有效方法，但也基于这样的想法，即只有一组 reducer 会响应一个给定的行动。虽然“ducks”规范确实建议从模块中导出 Action 常量，但这意味着您实际上不会拥有这些相互依赖性，因为没有其他模块会/应该关心另一个模块中发生的事情。

就其值(value)而言，Redux 的创建者丹·阿布拉莫夫 (Dan Abramov) 非常支持任意化简器处理相同的操作，并且通常不同意“鸭子”方法。显然只是一个意见，您绝对应该自由地做任何实际最适合您自己的应用程序的事情，但要考虑一些事情。

最终，我认为答案是您尝试使用“模块化”方法，但最终发现所需的行为实际上并未“模块化”。