为什么选择 Curry Redux 中间件：state => next => action {} vs. (state, next) => action {}答案

【问题标题】：Why Curry Redux Middleware: state => next => action {} vs. (state, next) => action {}为什么选择 Curry Redux 中间件：state => next => action {} vs. (state, next) => action {}
【发布时间】：2017-10-13 12:38:02
【问题描述】：

在阅读了中间件上的Redux's documentation 和applyMiddleware 上的source code 之后，我不明白为什么中间件需要咖喱语法：

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

做不到同样的事情

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

在applyMiddleware 中进行撰写调用：

dispatch = compose(...middleware)(middlewareAPI , store.dispatch)

【问题讨论】：

它可以，但由于混合，它可能看起来更混乱。另外，applyMiddleware 是唯一可以使用logger 的地方吗？
Idk 关于它看起来令人困惑的@Bergi，我可以更好地向自己和其他人解释它，说中间件需要一个存储和它需要调用的下一个方法，并从 next() 返回结果。这也使它类似于express.js
但是如果你必须解释它需要一个 store 和 next 方法，然后返回一个函数，该函数执行一个动作，并且......你仍然有一个柯里化函数，并且通过 mixing i> 使用 tuple 样式的 curried 样式您会感到困惑，以及为什么不简单地将所有内容都 curried 的问题。
哈哈因为它就像一个函数返回一个函数返回一个函数！

标签： javascript redux middleware

【解决方案1】：

可以在here 找到与 Dan Abramov 的讨论。他说，

我们本可以做到 (store, next) => action => () 但我没有看到一路走来的问题。您可能需要一些配置稍后，此时 options => (store, next) => action => () 看起来有点随意。

所以不，没有必要对参数进行柯里化。

【讨论】：

他们本可以要求中间件函数成为任何类型的 store、next、动作接收函数，无论是否咖喱。之所以是store=>next=>action，大概是因为是signature is easier to compose

【解决方案2】：

不，因为这是一种将函数推迟到稍后执行的方法。 ()=>() 返回一个函数对象，该对象仅在稍后调用 func obj 时执行。

【讨论】：

const logger = (store, next) => action => { .. } 仍然是一个延迟函数。