I could never get into the whole "side-effects for async code" pattern so many people are using with Redux. At my current gig, we are using redux-observable, and that's a WHOLE lot for people to grok to simply ... `await fetch('/users')`. I do agree, redux-sagas is much more in line with what I would expect.
But they all lead to things I would consider "hacky". Since it's all side effects, making sure two things that are "side effects" of the one action run in consistent order can be troublesome, since it's usually down to "well which one registered with the middleware first?"
And, if you ever need to actually simply `await` an action, you need to set up some middleware that will give you a promise that resolves / rejects when certain actions happen. Then you need to tie metadata to your actions if it stands that multiple of the action you're waiting to resolve happen.
Or, some people recommend creating a promise before dispatching, passing that promise reference around, checking for it in your sagas / observable.
All things I would consider super hacky.
I've been using my own middleware for years that simply lets you make `payload` a function, async function, or promise, and it's all incredibly more stable when things get complicated, and newcomers can grok whats going on in a second. You get `/start`, `/success`, `/error` actions baked in. And since it's promise-based, you can `await dispatch()` when you need to. If you need to get the state, or dispatch more actions, you can, right from the original action.
For times when you truly do want something to be a side effect (read: incredibly rarely because my actions have access to `dispatch` and `getState`), I use a very simple middleware like redux-saga but with standard async / await syntax.
I've been intrigued by people praising these side-effect workflows for some time, but after using redux-observable, I don't think I'll ever go near them again.
Apologies for the rant.