React-query: QueryResult are too generic

[CreativeTechGuy]

Describe the bug
QueryResult has a lot of generic types when more specific types could be used to make code easier to write and less assertions/checks necessary to use the various return values. For example, if isSuccess === true then data will never be undefined. If isError === true then error will never be null, etc.

To Reproduce
Not sure about repro steps since this is a TypeScript issue/improvement.

Expected behavior
I'd expect the QueryResult type to be one of several distinct types for each of the possible combinations. This means that if isSuccess is true, then is* will be false and every other combination similar.

Screenshots
N/A

Additional context
N/A

[CreativeTechGuy]

This seems to be request that's been made several times now. #922 #1102 #1108

After reading through some of those arguments made it makes me feel like this library is trying to do too many things at once. Given that any possible combination of status and data is technically possible, you can pass almost anything as a querykey, etc. I wonder if there's an argument here for being a bit more opinionated. It's great to have a simple library with only a dozen methods exposed but if each of those can be called with 20 different combinations of arguments it becomes really confusing to use and even harder to Type strictly. It seems like this may be because the library has grown so fast with so many new features and use-cases that things keep getting overloaded when really they should be refactored and more focused.

[TkDodo]

Given that any possible combination of status and data is technically possible

I don’t think that’s the case. React-Query has a “state-machine” internally, which makes sure you’re never in an impossible state. The flags (isLoading, isError) are derived from the “status” field.

There is some discussion going on in this PR: https://github.com/tannerlinsley/react-query/pull/1108

But it seems that making a discriminated union type (tagged by the status field) work without giving up internal type safety is not easy, and arguments have been made that checking for availability of data first seems better anyways so that you always display data if you have it.

[tannerlinsley]

Discriminated unions have been added to v3.