How can I determine if a UseQueryResult is enabled or not?

[jcready]

A custom hook might return a useQuery(). How can the consumer know if the query is enabled or not?

[TkDodo]

What do you want to achieve by knowing that? Generally, a query cannot be enabled or disabled - only an observer can. The query is still subscribed to the cache and will return cached data - enabled or not. enabled:false just means: This observer won't fetch data by itself. And that info usually isn't that relevant.

If you write a custom hook, you would have to return that information alongside your query, e.g.:

const useMyHook(some, inputs, here) => {

 const enabled = some(inputs, here)

 const query = useQuery(queryKey, queryFn, enabled)

 return [query, enabled]
}

[jcready]

The UseQueryResult has .refetch() which will trigger the queryFn which we may not wish to do if we know the inputs to be invalid which is why the producer of the useQuery() call would set enabled: false (since it has knowledge about if the query inputs are valid). Why would .refetch() be exposed, but not whether the query is enabled or not? The consumer is lacking knowledge needed to make an informed decision about if .refetch() can/should be called or not.

Just generally I wish the UseQueryResult provided a whole lot more information. Like, just expose the entire query options somehow even via some function which only provided the query options at that point in time.

[TkDodo]

you can use queryClient.refetchQueries, which will respect enabled. refetch is unconditional because it's meant to be the thing to bypass enabled

[jcready]

Using queryClient.refetchQueries means the caller needs to know at least the queryKey, and probably needs to know the queryFn. Neither of which are provided by the UseQueryResult which is the thing being passed around. And refetch is unconditional, but again, the consumer lacks knowledge about if it should refetch.

It's unclear to me why UseQueryResult has to hide (or at least won't expose) all kinds of useful information (queryOptions) when we know it's available in its scope. Is the reason technical or just philosophical?

[TkDodo]

we have access to all the options so we can return options on the result, which would then be everything you passed in. Given that we also merge multiple layers of defaults, it might be good to know what was actually used. It feels a bit like an axios respsonse returning the request config as well (which it does).

Do you want to contribute this?

[Jac0xb]

doom guy didnt want to contribute :(