What do I mean by that? The applications that I work on do a lot of composition of apis, reshaping the data and caching on the frontend since our backend teams are micro services teams. What happens is that our codebase needs to define multi api workflows and data transformations which we define using redux sagas or react query (we either adopt one or the other for the codebase).
The problem with the react query way of doing this is that the query has its own built in lifecycle it goes through stale -> fetching -> loading -> success/fail this is implicit behavior that you don’t have visibility into why it is making a transition. It becomes very painful for large workflows of api compositions to debug this kind of implicit behavior.
Redux sagas on the other hand is explicitly defined. We have these channels of communication over which messages are defined (actions) which cause some explicitly defined behavior to happen (sagas, reducers). Now why is this problematic? In a large codebase of micro services transactions we are dispatching actions in response to a parent action forming an explicitly defined implicit behavior.
So for example with react query if I am debugging an unexpected state in prod for a bug I have to reason about the way react query is processing a query in order to debug it due to the implicit behavior. In redux sagas world I have to reason about the implicit state machine of actions, sagas and reducers that a workflow kicks off.
This is why I don't like these two styles of organizing the application state. It becomes difficult to reason about the behavior but the redux/redux sagas way is easier to reason about because at least we explicitly defined the implicit behavior.
Also make sure to note I am talking about a complex web app on a micro-services api (frontend does a lot of api composition work), I am sure these are elegant solutions in the right context.