0

To define a middleware in redux we need to write a cascade of functions like:

const middleware = middlewareApi => next => action => {
    //logic here
}

The question is whether this signature is:

  • imposed by any necessities / opens any opportunities;
  • just the implication of Redux's implementation details / comfortable for developers to manipulate an array of (next)-argumented functions like here

Could it be replaced with the following signature (with with corresponding changes to Redux's code of course):

const middleware = (middlewareApi, next) => action => {
    //logic here
}

I realize that the result not totally equivalent to the former one but doesn't seem it makes any difference for the applyMiddleware case. The benefit that this syntax is less confusing IMO.

origaminal
  • 2,065
  • 1
  • 11
  • 19
  • the current API is more flexible than the one you propose: It gives the middleware author 3 lifetime hooks (when the middleware is bound to redux, when it is added to the MW pipeline, and when a redux action occurs. This gives more options for defining the scope of any local state the middleware needs – Brandon Oct 16 '17 at 17:11
  • I call this pattern cheap curry. It provides ultimate flexibility to pass around partially applied functions at the cost of a couple extra parens. – ktilcu Oct 16 '17 at 17:22

1 Answers1

1

We have a new "Design Decisions" FAQ page that answers this. (The docs have not yet been republished with the new content, so I'm linking the Markdown file.)

As the other comments mentioned already: currying is a standard functional programming technique, and in this case it helps provide closures where a middleware author can store values that need to be accessible across the life of the middleware.

Please see the FAQ entry for links to prior discussions on the topic.

markerikson
  • 63,178
  • 10
  • 141
  • 157