I would argue that its the opposite. It seems that redux is adamantly resisting the temptation to expand its scope and is sticking to its original promise of being a state container that undergoes state transitions via the composition of functionally-pure reducer functions and nothing more.

Yes redux is a store but it has middlewares like redux-thunk, redux-promises, and promises that lets you manage all the async actions you require.

One of the primary intents behind the creation of Redux was that it would provide structure for synchronous state updates, but leave handling of async logic and methodology as a plugin system. Middleware was explicitly intended to be an extension point that would allow users to plug in their preferred approach for handling async behavior (as opposed to libs like Flummox, which had a promise-handling capability built in, but no way to modify it or use anything else). I recapped the intentions behind Redux's creation in my blog post "The Tao of Redux, Part 1 - Implementation and Intent" [0].

The idea of Redux middleware has been an unqualified success. There's several hundred middlewares now available, covering a wide range of capabilities like general async side effects, API abstractions, logging, action transformation, and much MUCH more. I have a list of just about every existing Redux middleware [1] in my Redux addons catalog [2] .

The most common Redux async side effect middlewares allow you to handle your async logic via your preference of syntax and implementation: simple functions, promises, generators, observables, or even Elm-style descriptive effects. I listed the most popular side effects libs in "The Tao of Redux, Part 2 - Practice and Philosophy" [3], there's a really good article comparing the various approaches at [4], and I have more articles on Redux side effects listed at [5].

This particular middleware appears to be primarily for transforming the contents of actions as they pass through the middleware pipeline, with the ability to resolve the transformations synchronously or asynchronously. This would likely be useful in ensuring that responses from an API have been transformed into a consistent format before they are processed by the Redux store. So, it doesn't look like it handles or implements async behavior itself, but rather allows you to write transformation logic that can be async.

[0] http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao...

[1] https://github.com/markerikson/redux-ecosystem-links/blob/ma...

[2] https://github.com/markerikson/redux-ecosystem-links

[3] http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao...

[4] https://decembersoft.com/posts/what-is-the-right-way-to-do-a...

[5] https://github.com/markerikson/react-redux-links/blob/master...