Javascript 为什么使用Curry Redux中间件：state=>；下一步=>；动作{}vs.（状态，下一步）=>；动作{}

在阅读了中间件和applyMiddleware之后，我不明白为什么中间件需要curry语法：

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
}

正在进行撰写调用：

---

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

可以找到与丹·阿布拉莫夫的讨论。他说,

我们本可以做到（商店，下一个）=>action=>（），但我看不到任何成功 一路走来的问题。您可能需要一些配置 稍后，options=>（store，next）=>action=>（）将在哪一点进行查看 有点武断

---

因此，不需要对参数进行修饰。

可以，但由于混合的原因，看起来可能会更混乱。另外，

applyMiddleware

是唯一可以使用

logger

的地方吗？Idk关于它的说法看起来很混乱@Bergi，我可以向自己和其他人解释，最好说中间件需要存储和它需要调用的下一个方法，并从next（）返回结果。这也使得它类似于

express.js

，但如果您必须解释它将一个存储和下一个方法结合在一起，然后返回一个执行操作的函数，那么……您仍然有一个curried函数，并且将curried样式与tuple样式混合，您会感到困惑，还有一个问题，为什么不是所有的东西都是咖喱菜。哈哈，因为它就像一个函数，返回一个函数，返回一个函数！const logger=（store，next）=>action=>{..}仍然是一个延迟函数。它们可能要求中间件函数成为任何类型的store，next，action receiving函数，curried与否。它之所以是store=>next=>action，可能是因为它

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