Typings of useQuery({ throwOnError:true }).data should not depend on query.isError

[AriPerkkio]

This is a feature request to improve return type of useQuery when throwOnError is set to true.

Reproduction: https://stackblitz.com/edit/vitejs-vite-pg39ou?file=src%2FApp.tsx

Relevant code:

function SomeComponent() {
  const query = useQuery({
    queryKey,
    queryFn,
    throwOnError: true,
  });

  if (query.isPending) return <div>Loading</div>;

  // This is never reached but is required for Typescript
  if (query.isError) return <div>Error</div>;

  return <div>Data {query.data.someResponse}</div>;
}

Typings of the return type require checking for .isError even though that property should never be used. The function call of useQuery throws the error instead of adding it into return value.

I would expect this to pass typechecking:

function SomeComponent() {
  const query = useQuery({
    queryKey,
    queryFn,
    throwOnError: true,
  });

  if (query.isPending) return <div>Loading</div>;

-  // This is never reached but is required for Typescript
-  if (query.isError) return <div>Error</div>;

  return <div>Data {query.data.someResponse}</div>;
}

But the query.data is nullable as .isError has not been checked for narrowing down the type.

As throwOnError can also be function that returns boolean, this improvement can only be used when throwOnError is set to true explicitly.

As work-around for now I think I'll be using following:

  if (query.isPending) return <div>Loading</div>;

  // Error is already thrown but typings require checking it
  if (query.isError) {
    throw query.error;
  }

  return <div>Data {query.data.someResponse}</div>;

[alexanderchr]

This would be great to have and I think quite easy to change typings for. Problem is that you'd need to need one overload for each combination of options that affect the return type in useQuery.ts. Would a PR for this be considered?

[VictorienDruon]

Any updates on that ? this would improve greatly dx

[TkDodo]

it's honestly too much complexity to add a bunch of overloads just for this, and it also won't be as helpful in practice because it would only work if you pass throwOnError: true directly to useQuery. We've done this for initialData, but that's a setting you most often pass locally. throwOnError is something that most people set globally.

What you can do is:

• just check for if (data) first and then render data. It's often the better order anyways. See: https://tkdodo.eu/blog/status-checks-in-react-query
• useSuspenseQuery. That's what I'm doing :)

[AriPerkkio]

It's been a while since I reported this, but if I remember correctly, I think I ended up wrapping useQuery and handling the case there. TS would then infer the types correctly when used in components:

export function useQueryWithThrowOnErrorEtc(options) {
  const query = useQuery({
    ...options,
    throwOnError: true,
  });

  // Error is already thrown but typings require checking it
  if (query.isError) {
    throw query.error;
  }

  return query;
}