Suggestion: Reorganization of Middleware Logic and Structure

[isocroft]

Midlewares work great already in Redux.

However, as pertains this issue we all discover that there are edge cases to the way it is works as implemented via nested closures (2 of them). I do understand why this is necessary owing to the way Redux works. However, this level of composed functions does unsettle some devs who would like to use Redux extensively and i was wondering if the code structure and logic (applying the middleware as some sort of decorator around the store.dispatch method) can be reorganized a bit to look like the middleware implementation in this project.

Here is the Radixx README file which contains example code.

This is just a suggestion... any takers ?

[markerikson]

If you're proposing that we change the middleware signature to be a single function with multiple args instead of the current nested/curried function structure, then no, we're not going to change that. See the "Design Decisions" FAQ entry on why middleware are written as curried functions for links to prior discussion.