Improve Type Consistency for Developer Experience

[ellemedit]

Currently, useQuery always returnQueryObserverResult<D, E> even if we set suspense, error boundary or enabled options. For example)

const query = useQuery(cacheKey, queryFunction, { enabled: true, suspense: true, useErrorBoundary: true });
// we should use null assertion here
query.data!

// or need to check status
if (query.status !== 'success') {
  throw new Error('bug');
}
query.data

what if state is limited by configuring options?

useQuery(cacheKey, queryFunction); // can be idle | loading | success | error
useQuery(cacheKey, queryFunction, { enabled: true }); // can be loading | success | error
useQuery(cacheKey, queryFunction, { enabled: true, suspense: true }); // can be success | error

// can be only success, no need to branch by condition!
useQuery(cacheKey, queryFunction, { enabled: true, suspense: true, useErrorBoundary: true });

pros

• user can predict state more easily. mentally different.

cons

• it might be slower in typecheck

caveat

• there is no way predict state with queryClient override options.

PoC
https://codesandbox.io/s/determined-yonath-bg5oq?file=/src/usePerformQuery.ts:1572-1606 (implementation)
https://codesandbox.io/s/determined-yonath-bg5oq?file=/src/UserProfile.tsx (usage example)

[TkDodo]

useQuery(cacheKey, queryFunction, { enabled: true }); // can be loading | success | error

I think calling queryClient.resetQueries(cacheKey) would still get your query back to idle state. Also, if your query is currently fetching for the first time (might take longer e.g. with retries), and you cancel that fetch (queryClient.cancelQueries - often done with optimistic updates), the query goes back to the last successful state, which is idle.

so, I'm not so sure this is the right way to go. Even though idle doesn't come up often, we can't just exclude it because of the enabled flag.

---

having the possibility to type narrow depending on props passed to useQuery, for things like suspense, initialData or placeholderData though has been requested a lot, but I think it's very hard to do and requires a ton of generics. Please keep in mind that you can also set those things globally on the QueryClient, or via queryClient.setQueryDefaults, so to get this working 100% for all levels is nigh impossible. But having it work for direct options on useQuery would be an improvement for sure.

If you are up for it, please create a PR. Your PoC already looks quite complex imo, but I'm happy to take a look at an actual PR. We have to balance the benefit vs maintainability for sure, but I'd love if we could get this done :)

[ellemedit]

I got the point. I'll consider that edge cases. and if I find a solution, I'll make a PR.