[proposal, workarounds] Dependent and optional queries share an overloaded API

[asktree]

Context: I am working in web3, so there are long chains of dependent queries because we can't simply make relational queries on the backend. I am also using react-query, I really don't know if this applies to any other of the packages or not.

problem

Right now if you want an optional query, you pass the conditional to theenabled option of useQuery. If the fetchStatus is 'idle' then you can conclude that the query won't run.
Right now if you want an dependent query, you pass something like myDependencyQuery.data !== undefined to enabled option of useQuery. If the fetchStatus is 'idle' then you can conclude that the dependency query is still loading.

But what if your query is both optional and dependent? You can't tell if it's idle because the dependencies are still loading, or if its idle because it's just never coming.

some solutions

ideal API

To me the ideal API is that enabled is broken up into ready and enabled. By default everything is ready and enabled.
If something is enabled but not ready, it has {status: 'loading', fetchStatus: 'idle}. If something is not enabled (ready or not), then it has {status: 'disabled', fetchStatus: 'idle}.

This seems most intuitive to me, but would be a really annoying breaking change I'm sure.

non-breaking API

You could make enabled have type boolean | {ready: boolean, disabled: boolean} or something. And if options.enabled.disabled === true then status is disabled. IDK.

workaround

Right now you could use the query meta option to include something like {disabled: boolean}. This would require some extra code along each query in the chain that you write, since it now needs to take normal arguments as well as the disabled meta-status. I have not yet tried this out.

[TkDodo]

it seems like you want a return value for something that you already know, as you pass it into an option of react-query. consider:

const isEnabled = someCondition()
const isReady = someOtherCondition()

const { status, fetchStatus } = useQuery({ queryKey, queryFn, enabled: isEnabled && isReady })

now you don't have to inspect status or fetchStatus to know what state the query is in. For react-query, there is only one state - the query(observer) is disabled. Internally, there is no need to differentiate: it doesn't matter why the query isn't running.

if it matters to you, you can still check for isEnabled or isReady - the variables / conditions you have implicitly available because you passed them to react-query:

if (status === 'loading' && fetchStatus === 'idle') {
  if (isReady) { .... }
  else { ... }
}

[asktree]

Hmm. Yeah okay that makes sense that internally there is no reason for react-query to care why a query isn't running.

It's a little more complicated because I'm composing many custom query hooks in a chain. So this isReady / isEnabled state needs to drill through each one, though I suppose that is true with any of my proposals too. I will ponder this more, thanks.

[asktree]

Yeah I mean I am just being stupid. You are right that I am just asking react-query to tell me only information that I already know and told it to begin with. Makes sense that react-query would not care about doing this.