使用redux store的dispatch实例与传入dispatch作为参数答案

【问题标题】：using redux store's instance of dispatch vs. passing in dispatch as parameter使用redux store的dispatch实例与传入dispatch作为参数
【发布时间】：2016-10-01 00:49:31
【问题描述】：

在docs 中，Dan 没有给出太多理由来改变调度传递到中间件的方式。他只是这么说：

但也有另一种启用链接的方法。中间件可以接受 next() 调度函数作为参数而不是从 store 实例中读取它。

这是什么原因？对我来说，现在applyMiddleware 中的代码将采用存储和调度的 2 个参数，而不是单独存储，这看起来更奇怪了。

【问题讨论】：

标签： javascript redux middleware react-redux

【解决方案1】：

看起来怪怪的不是问题。

const logger = store => next => action => {
  console.log('dispatching', action)
  let result = next(action)
  console.log('next state', store.getState())
  return result
}

请注意，函数式语言默认具有这种格式，并且完全正常。

这样做的原因是猴子补丁尚未确立为推荐的编程方法。将next 传递给函数更加灵活，并且不需要调用函数（开发人员的函数）的任何内容，从而减轻了开发人员的负担并降低了出错的机会。

最后，Dan 喜欢解释为什么他以某种方式编写代码，但作为 lib 用户，我们低级的开发人员并不是决策者。 decision has already been made 这是在 Redux 中使用中间件的方式。您可以随时 fork Redux 并根据自己的喜好对其进行修改，但请注意 Redux 的强大之处不在于 lib 中的代码，而是由 3rd 方开发人员附加到它的代码。如果不一起玩，你就会放弃所有的权力。

【讨论】：

“格式”（更准确地定义为一种技术）称为currying。

【解决方案2】：

这是一个非常常见的问题，我将很快将其添加到 Redux 常见问题解答中。

简短的回答是，Redux 深受函数式编程原则的影响，而柯里化是 Dan 和 Andrew 在进行初始设计时碰巧采用的方法。一旦选择了它，它基本上就保持这种兼容性。

最初的设计在 Redux issue #55 中进行了讨论，Dan 提出了重写，然后在 issue #1744 中拒绝了他自己的提议。

【讨论】：