[acemarke]

Well, one of the primary design goals behind Redux was to make async behavior a pluggable approach (as detailed in my blog post "The Tao of Redux, Part 1 - Implementation and Intent" [0]).

So, I don't see how use of redux-saga, or redux-thunk, or any other async middleware, qualifies as "bending Redux until it does their bidding", given that it was explicitly intended to allow that.

On the other hand, there definitely _are_ lots of ways that people "bend Redux", especially things like trying to slap OOP layers on top of an FP-oriented library. Those are technically valid because the Redux core is very unopinionated, but they're definitely not idiomatic Redux usage. (I also discussed those in "The Tao of Redux, Part 2 - Practice and Philosophy" [1]).

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

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

[k__]

I used Redux back in the days and async behavior felt rather clunky (action begin, action success, actionFailure) the other approaches felt like somehow getting rid of this clunky stuff.

Using observables instead of Redux doesn't even lead to these fixes.

[acemarke]

As I describe in that "Tao of Redux Part 2" post, there's no _requirement_ that you dispatch START/SUCCESS/FAILURE actions as part of your async requests. You'd need SUCCESS at a minimum or an equivalent to handle the actual updates from the request, but the START/FAILURE actions are only needed if you want want to do things like showing spinners or have some kind of undo/redo behavior. It's a useful convention and a common pattern, but definitely not a requirement.