为何不对Redux Action Creators进行「预连接」？

这是个非常棒的问题！咱们从Redux的设计初衷、实际开发痛点和最佳实践的角度来拆解，核心原因围绕灵活性、耦合度、代码清晰性这几个关键点展开：

1. 会丧失灵活性，绑定到特定Store实例 #

如果把action creator提前和dispatch绑定（也就是预连接），意味着这个函数会直接依赖某个具体的Redux Store实例，这会带来不少麻烦：

• 测试难度陡增：测试组件或工具函数时，你没法轻松替换成mock store，只能依赖真实的全局Store，测试的隔离性完全丧失。比如预连接了addFoo，测试时想验证它是否被调用，就得操作真实Store的状态，而非用一个可控的mock环境。
• 多Store场景直接失效：在服务端渲染（SSR）或需要多个独立Store的场景下，每个请求/实例都需要专属的Store，预连接的action creator只能绑定到第一个创建的Store，根本无法复用。

对比两种写法更直观：

• 纯action creator（推荐）：

  // Actions.js
  export const addFoo = foo => ({ foo, type: 'ADD_FOO' });
  

  这个函数不依赖任何外部环境，拿到就能用，想怎么dispatch就怎么dispatch。

• 预连接的写法（不推荐）：

  // Actions.js
  import store from './store';
  export const addFoo = foo => store.dispatch({ foo, type: 'ADD_FOO' });
  

  直接绑定到全局store，完全没法在其他Store环境下使用。

2. 过早耦合，破坏纯函数特性 #

Redux的action creator设计初衷就是纯函数：接收参数，返回描述动作的plain object，不依赖任何外部状态或框架。预连接会把它变成依赖Redux dispatch的函数，彻底破坏通用性：

• 你没法在非Redux环境下复用这个action creator，比如某个工具函数需要生成action对象，或者切换到其他状态管理库时，这个函数就彻底没用了。
• 代码职责边界模糊：原本action creator只负责“描述动作”，预连接后它还要负责“触发动作”，违背了单一职责原则。

3. 无法利用Connect的优化机制 #

React-Redux的connect函数本身自带不少优化：

• 当你把action creator对象传给mapDispatchToProps时（比如例子里的const mapPropsToDispatch = { addFoo }），connect会自动用bindActionCreators处理，并且只会在组件初始化时创建一次绑定后的函数，避免重复创建带来的性能损耗。
• 如果预连接，你会提前创建绑定函数，不仅没法享受到connect的优化，还可能导致不必要的函数重复创建（比如在组件外部每次导入都生成新函数）。

4. 代码可读性与维护性下降 #

保持action creator的纯函数特性，能让代码逻辑更清晰：

• 新人一看就知道addFoo是生成action的函数，而非直接触发动作的函数。
• 当需要修改动作的触发逻辑时，你只需要在组件的connect部分调整，不用去修改action creator本身，降低了维护成本。

那什么时候可以预连接？ #

其实也有极少数场景可以这么做，比如你有一个全局工具函数，确定只会在当前Redux Store环境下使用，而且不需要测试隔离。但这种情况非常少见，直接用store.dispatch(addFoo(5))反而更直观，没必要预连接action creator。

总结下来，保持action creator的纯函数性，在组件层面通过connect绑定dispatch，是Redux社区公认的最佳实践——它兼顾了灵活性、低耦合性和代码清晰性，能让你的代码在长期维护中更省心。

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