Type narrowing lost when destructuring the result of useQuery

[kykungz]

It works fine when using the useQuery hook directly:

const App = () => {
  const { data, status } = useQuery({
    queryKey: ["abc"],
    queryFn: () => "hello world"
  })

  if (status === 'success') {
    // data is correctly a `string`
  }
}

However, if I wrap my useQuery in another custom hook like this, I will lose my type narrowing functionality:

const useMe = () => {
  const queryResult = useQuery({
    queryKey: ["abc"],
    queryFn: () => "hello world"
  })

  return [queryResult, 'John Doe'] as const
}

const App = () => {
  const [{ data, status }, name] = useMe()

  if (status === 'success') {
    // data is still `string | undefined`
  }
}

But, if I do not destructure the first returned item, the type narrowing is back:

const App = () => {
  const [queryResult, name] = useMe()

  if (queryResult.status === 'success') {
    // queryResult.data is now `string`
  }
}

How do I correctly create my custom hook so that it also works with destructuring assignment like the original useQuery?

[TkDodo]

this should work with TypeScript 4.6 and higher: https://devblogs.microsoft.com/typescript/announcing-typescript-4-6/#cfa-destructured-discriminated-unions

[kykungz]

@TkDodo The normal destructured discriminated union works fine, but it doesn't work on a destructured array.

But thank you for pointing the way, I found the right word to search for this issue, until I found this one: microsoft/TypeScript#55664

[kykungz]

It seems to be a missing feature of TypeScript, that type narrowing doesn't work when destructuring discriminated union within a destructured array.

microsoft/TypeScript#55664

[TkDodo]

TIL, thanks 🙏

[token-ed]

I have a similar question but more related to destructuring useQuery/useMutation API properties into an object.
The idea is that I want to create an abstraction on top of useQuery and useMutation so that I restrict their APIs and I expose my own set of properties to UI components (I don't need the whole set of features from useQuery/useMutation, as a matter of fact a small part of them covers 100% of the behaviors I need).
The issue is that I lose TypeScript narrowing and would have to either manually implement it myself or expose everything from useQuery/useMutation

Let's assume this is my abstraction on top of useQuery:

export function useGet() {
  const { data, isError, isPending, isSuccess, error } = useQuery({
    queryKey: ["hello"],
    queryFn: async () => "Hello World"
  });

  return {
    error,
    data,
    isError,
    isPending,
    isSuccess
  };
}

Then, in my UI component I use that abstraction:

const HelloWorld = () => {
  const { data, isError, isPending, error } = useGet();

  if (isError) return `Oops, something went wrong: ${error}`;

  if (isPending) return "Loading...";

  return (
    <>
      {data}
    </>
  );
};

Because I am destructuring the features from useQuery and exposing them from useGet, when useGet is called in HelloWorld component, TypeScript loses the narrowing functionality. Test it out in here

If I expose the whole useQuery API, I will have TypeScript correctly inferring the narrowed types of data.

[token-ed]

To anyone struggling with the same, I found a way to solve it: spread operator has 2 symmetrical forms: spread and rest. If you use the latter in your benefit, you will make TypeScript keep narrowing and inferring your custom api props.

In the code above, you would have to do something like this:

export function useGet() {
  const {
    somePropIDontWantToExpose1,
    somePropIDontWantToExpose2,
    somePropIDontWantToExpose3,
    somePropIDontWantToExpose4,
    somePropIDontWantToExpose5,
    somePropIDontWantToExpose6,
    ...myCustomApi
  } = useQuery({
    queryKey: ["hello"],
    queryFn: async () => "Hello World"
  });

  return myCustomApi;
}

It still looks a bit crooked but that is what I could come up with.

I might be wrong but I think I've read @TkDodo commenting before on this, that we shouldn't really build abstractions on top of base implementations like useQuery. Would love to hear your opinion on it if you ever come across this thread again.

Cheers!

[TkDodo]

...myCustomApi opts out of some optimisation features we have:

• https://tanstack.com/query/v5/docs/eslint/no-rest-destructuring
• https://tanstack.com/query/v5/docs/framework/react/guides/render-optimizations#tracked-properties

I would rather build abstractions on top of queryOptions:

• https://tkdodo.eu/blog/the-query-options-api
• https://tanstack.com/query/latest/docs/framework/react/reference/queryOptions#queryoptions

[token-ed]

@TkDodo That is valuable info right there! Thank you!