I use Sagas as well though, and Ive found them ok...really easy to test but feel very heavyweight and clunky; personally, I don't _really_ like the loading/error state to be handled by Redux: the more years I work on React/Redux app the more I prefer for a section of an app to be mounted -> triggering a fetch -> loading, show local loading UI -> {fails, show local UI|succeeds, dispatch success}. So Redux becomes a serializable normalized data cache that acts to store the results of disparate API calls and doesn't care at all much about the UI.
There's a tremendous amount of work out there for how to get redux to completely handle async and branching methods, and I think the best solution for most cases is to not have it handle any of that.
Keep your data fetching in normal everyday functions, have react components call those and funnel the data you need in the global store back to redux, and then have the components that need that data read it from the global store.
Edit: If you do need to synchronise multiple async updates to that state that happen in a very short space of time & in an unknown order in a controlled way, then yeah something like sagas is a solid choice to exert control over that. But very often the user of the UI is only going to make one request [or one batched set of requests] -- eg I am working on an RN app at the minute, and each screen does need to fetch data. So I fetch in the component, it shows loading etc, then populates the store. If the user cancels what they're doing (navigate away for example), the component used to fetch unloads and no dispatch is made.
I've got nothing against any of them, I've used almost every major one in my jobs over the last few years. But I (and the person who replied to me) both seem to feel the same way, that in many cases just fetching in React, in the component, is all that is needed, let the Redux application deal with marshalling the resultant state (which it is very good at)
but how do you put the result back in the store? how about displaying a default failure screen?
The API request is in the file that represents the point at which the API request is made by the user (previously in a loader component or, now, using a hook, in future using suspense), so I would say it involves jumping through 0 files, as opposed to several if I move it to redux (the dispatch occurs at the UI trigger point, then I have to drill through several other layers of abstraction). In practice there's normally some facade in front of the API to prefill values and also to make it easier to mock for testing, but if anything that just makes it simpler as the facade acts as a reference.
> how about displaying a default failure screen?
failure && <FailureComponent>{failure.message}</FailureComponent>
> but how do you put the result back in the store?
dispatch({ type: "foo", data: "bar"})
In our main app we also use advanced features like what Slack is describing in their post, like having multiple Redux stores. We also combine stores from multiple sources (e.g. appStore = [...store1, ...store2, ...storeFromALibrary]. It's incredibly flexible.
Something like Redux Saga, Redux Thunks, Redux Observable (my personal preference here), or what have you, are the higher order "toolsets" that Hooks alone aren't likely to replace yet. It may be the case that some of them are going to start targeting Hooks/Context more directly without "needing" an intermediary state engine like Redux, but it's also entirely possible that it will still remain a good reason to make a step change to a state engine like Redux when you find yourself needing higher-order coordination between components that libraries like Sagas, Thunks, or Observables can provide.
Under the hood it uses [cofx](https://github.com/neurosnap/cofx) which is a library I wrote to solve the need to write declarative side-effects without redux.