触发Action后执行函数的最佳实践及函数存放位置咨询

针对你遇到的这种「在特定Action（REAL_ACTION）触发后执行清除Codemirror历史」的场景，我整理了几个符合Redux最佳实践的方案，结合你的具体情况拆解：

1. 自定义Redux中间件（推荐，最规范） #

你之前考虑过用中间件，但思路可以调整——不用检测FAKE_ACTION，而是直接监听REAL_ACTION的触发，因为你的目标是在这个Action被reducer处理完成后执行副作用。

中间件是Redux官方推荐用来处理跨切面副作用的方式，完全符合规范。你可以写一个专门的中间件，在Action流经reducer之后执行你的清除逻辑：

// 自定义中间件
const clearCodemirrorMiddleware = store => next => action => {
  // 先让Action正常流向reducer处理状态更新
  const result = next(action);
  
  // 判断是否是目标Action
  if (action.type === 'REAL_ACTION') {
    // 执行清除Codemirror历史的逻辑
    $('.CodeMirror').each(function() {
      this.CodeMirror.clearHistory();
    });
  }
  
  return result;
};

// 将中间件加入Redux store的配置中
const store = createStore(
  rootReducer,
  applyMiddleware(clearCodemirrorMiddleware)
);

这个方案的优势：

• 完全遵循Redux数据流，副作用逻辑和状态更新逻辑解耦
• 只在目标Action触发时执行，性能开销小
• 代码可复用，后续如果有其他Action需要类似处理，直接扩展中间件即可

2. 在REAL_ACTION的触发点直接调用（最直观） #

如果你有权限修改「取出REAL_ACTION并触发」的那段代码，这是最直接的方式——在dispatch(REAL_ACTION)之后立即执行清除函数：

// 假设这段是你项目中取出并触发REAL_ACTION的代码
const actionList = store.getState().yourActionListKey;
const realAction = actionList.find(action => action.type === 'REAL_ACTION');

// 触发Action
store.dispatch(realAction);

// 立即执行清除逻辑
$('.CodeMirror').each(function() {
  this.CodeMirror.clearHistory();
});

这个方案的优势：

• 逻辑直观，不需要额外的中间件或监听
• 没有额外的状态监听开销，性能最优
• 代码可读性强，后续维护者一眼就能看到Action和副作用的关联

3. 使用Redux的subscribe方法（备选，适合无法修改核心代码的场景） #

如果上述两种方案都无法实施（比如完全不能修改中间件配置或Action触发代码），可以用Redux的subscribe方法监听状态变化，判断是否是REAL_ACTION触发的更新，再执行清除逻辑：

// 记录最后一次触发的Action类型
let lastActionType = null;

// 先通过一个简单的中间件记录最后一次Action类型
const trackActionMiddleware = store => next => action => {
  lastActionType = action.type;
  return next(action);
};

// 配置store时加入这个中间件
const store = createStore(
  rootReducer,
  applyMiddleware(trackActionMiddleware)
);

// 监听状态变化
store.subscribe(() => {
  if (lastActionType === 'REAL_ACTION') {
    // 执行清除逻辑
    $('.CodeMirror').each(function() {
      this.CodeMirror.clearHistory();
    });
    // 可选：重置lastActionType，避免重复执行
    lastActionType = null;
  }
});

这个方案是兜底选项，因为subscribe会在每次状态变化时触发，所以需要额外跟踪Action类型，相对前两种方案略繁琐。

总结建议 #

优先选择方案1（自定义中间件），它最符合Redux的设计规范，也能很好地解耦副作用和状态逻辑；如果你的项目中可以直接修改REAL_ACTION的触发代码，方案2会更简单直观。

内容的提问来源于stack exchange，提问作者danday74