was there reason to drop union type support in useQuery?

[ellemedit]

https://github.com/tannerlinsley/react-query/blob/master/src/core/types.ts#L160

I used to use query like:

const query = useQuery(...);
switch (query.status) {
case 'success': {
  return <div>query.data</div>; // can sure that data exists in typescript
}
default: {
  return <div>; // cannot sure data exist
}

but the new types do not support union type because the union type dropped

[tannerlinsley]

@boschni

[ellemedit]

at this moment, I monkey patched like:

type MyQueryResult<D> = Omit<QueryResult<D, unknown>, "data" | "status"> &
  (
    | { status: "success"; data: D }
    | { status: "error"; data?: D }
    | { status: "idle"; data?: D }
    | { status: "loading" }
  );

[boschni]

Hi @beingbook! The discriminated unions have been dropped because they add quite a bit of types and some complexity while in my opinion, not bringing much value:

// A common pattern is to destructure the query result, but in doing so, the unions would have no effect:
const { error, data } = useQuery()

// In case someone did use the status property to discriminate:
const result = useQuery()

if (result.status === 'idle') {
  // Don't need to assert `data` and `error`
}

if (result.status === 'loading') {
  // Still need to assert `data` or `error`
}

if (result.status === 'error') {
  // Still need to assert `error`, because technically it could be anything
}

if (result.status === 'success') {
  // Now `data` is available, but we could have also asserted `data`
}

But as you pointed out, it's always possible to regain this functionality with a custom type.

[jelteliekens]

I really liked the discriminated unions. I used them like in your second example. After I checked that the query was not idle or not loading or no error occured I was sure data was filled and I didn't need to have an extra check but now I do.