Redux中间件中调用next后再分发新动作是否合规？

首先明确说：在Redux中间件中调用next(action)更新store后再分发新动作是完全可行的，而且这不属于反模式——这其实是Redux中间件设计的典型使用场景之一，非常适合你这种需要依赖更新后状态触发后续操作的需求。

为什么这是合理的？ #

Redux中间件的核心作用就是在动作的流转过程中（动作被发送到reducer之前/之后）插入自定义逻辑。当你调用next(action)时，这个动作会被传递到后续的中间件，最终到达reducer完成状态更新。此时再调用store.dispatch()发起新动作，就能确保你获取到的是最新的应用状态，完美匹配你需要用api.state.topStoryIds[api.state.loadedUpToIndex]的场景。

具体实现示例 #

针对你的需求，你可以编写一个专门处理fetchHackerNewsTopStoriesSuccess动作的中间件，示例代码如下：

Middleware<AppState> createPostTopStoriesMiddleware() {
  return (Store<AppState> store, dynamic action, NextDispatcher next) {
    // 只处理目标成功动作
    if (action is FetchHackerNewsTopStoriesSuccess) {
      // 先让store处理这个动作，完成状态更新
      next(action);
      
      // 获取更新后的最新状态
      final currentState = store.state.api;
      // 检查索引是否合法，避免越界
      if (currentState.loadedUpToIndex < currentState.topStoryIds.length) {
        // 分发获取下一个item的动作
        store.dispatch(fetchNextHackerNewsItem());
      }
    } else {
      // 非目标动作，直接传递给下一个中间件
      next(action);
    }
  };
}

需要注意的细节 #

1. 中间件顺序：确保这个中间件被正确添加到中间件链中，不需要特意放在某个位置（只要next(action)能触发reducer更新状态即可，这是中间件的默认流转逻辑）。
2. 避免无限循环：一定要添加边界判断（比如上面示例中的索引检查），防止fetchNextHackerNewsItem及其后续的成功动作再次触发这个中间件，导致无限分发动作。
3. 保持中间件单一职责：这个中间件只负责处理“成功获取top stories后触发下一个item请求”的逻辑，不要把其他不相关的逻辑塞进来，这样代码更易维护。

有没有其他替代方案？ #

如果担心中间件里dispatch动作的方式不够“纯粹”，还有一种可选方案是使用redux-thunk（如果你还没用到的话）：在触发fetchHackerNewsTopStories的thunk函数中，等待top stories请求成功、状态更新后，再手动dispatchfetchNextHackerNewsItem。不过这种方式需要你把异步逻辑放在thunk里，而你当前用中间件处理的方式已经很清晰，完全没必要替换。

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