Popular posts

If you’re into Rx, Redux Observable does pretty much what you describe: it’s a middleware that maps action streams with Rx. Here is a recent talk about it: https://www.youtube.com/watch?v=AslncyG8whg.

We didn’t want to prescribe something like this in Redux itself because we know a lot of people are not comfortable with learning Rx operators to do basic async stuff. It’s beneficial when your async logic is complex, but we didn’t really want to force every Redux user to learn Rx, so we intentionally kept middleware more flexible.

I agree that the difference between a "dispatchable" (something you pass to the dispatch method) and a proper "action" (the actual object which is sent to the reducer) can be confusing. We struggled with the right terminology for distinguishing these concepts in the docs. We landed on "async actions" and "actions" but I've never been that happy with those terms.

Observables are, indeed, a great abstraction for dealing with asynchronous control flow. Have you heard of Redux Observable? It seems to be exactly what you're looking for.

Also, as I mentioned in a different response, "[the] reason the middleware API exists in the first place is because we explicitly did not want to prescribe a particular solution for async." My previous Flux library, Flummox, had what was essentially a promise middleware built in. It was convenient for some, but because it was built in, you couldn't change or opt-out of its behavior. With Redux, we knew that the community would come up with a multitude of better async solutions that whatever we could have built in ourselves.