#2047 may have introduced a Typescript bug for queries generics

[lukemorales]

Describe the bug
Before #2047 being merged, I used to type useQuery with just useQuery<DataType, ErrorType> to cast the error from axios. After the merge, all my typed hooks broke because if I don't type all the 4 type parameters, Typescript is inferring the second parameter as the options object instead of the function, thus throwing a Type error, as shown by the screenshot[1].

It also broke the way I typed the queries object for useQueries, as I need now to type all 4 type parameters of each array object. It was easy and very handy to use the UseQueryOptions type for the auto complete, but now it's pretty unusable if I don't type all my queries types, and if it's a lot of objects with different types, it get's very verbose (screenshot[2]).

To Reproduce
Steps to reproduce the behavior:

1. Install latest version.
2. Only provide the two first parameters to useQuery generic and Typescript will complain about the query function not being typed correctly.
3. Install react-query version 3.12.2
4. Typescript will stop complaining.

Expected behavior
Typescript should infer the second parameter of useQuery as the query function even if only two parameters are provided to the type generics, but a different issue happens with the useQueryOptions, so I think the QueryKey inferring introduced by #2047 may have brought a more in depth issue.

Screenshots

[TkDodo]

Hmm I thought the change was backwards compatible because if you don’t pass a generic, the default value should kick in, which is the same as it was before 🤔. But if the wrong overload is chosen that would not be ideal. I’ll have a look 👀

[lukemorales]

Thanks for the quick reply @TkDodo, I've provided more accurate steps to reproduce just now!

[TkDodo]

A first quick test shows that this works fine: https://codesandbox.io/s/react-query-generics-7c5qp?file=/src/App.tsx

we also use these generics in our tests:
https://github.com/tannerlinsley/react-query/blob/7fe6e30bc1ab3f981582b190883893bd21a63f27/src/react/tests/useQuery.test.tsx#L109

can you provide a codesandbox example that shows the error please instead of screenshots?

[lukemorales]

@TkDodo the issue happens when the query function uses the context arg to get some variable it will use on the fetch function. Here's your example but with that implemented and Typescript getting the wrong overload: https://codesandbox.io/s/react-query-wrong-overload-0v71w

In the sandbox above, I'm typing just the context arg, but the error also applies if typing the function with the QueryFunction generic.

[TkDodo]

interesting. a couple of observations:

• if I switch back to 3.12.2, I get no type errors, but also no type safety. Nothing stops me from doing this:

  const { isLoading, error, data, isFetching } = useQuery<any, Error>(
    ["repoData", 1],
    fetchRepo
  );

thus passing an invalid queryKey to fetchRepo, which still expects [string, string]. That is because before the change, queryContext and the actual queryKey had no correlation - QueryFunctionContext was basically QueryFunctionContext<any, any>

• If I inline the fetchRepo function on the latest version, I can see that it is inferred to QueryFunctionContext<QueryKey, any>. and QueryKey does not correspond to the more narrow [string, string]. That is just because TypeScript does not have partial type inference (yet): if you specify two of four generics, the other two are not inferred, but the default values are always taken. That's why you get QueryKey for your key. I'm afraid there is currently no way around this: if you specify generics, you have to provide them all, or live with the default value that you get.

[lukemorales]

Yeah, great points and I agree with you. But it's still getting the wrong overload.

If you hover the fetchRepo error in codesandbox you will see Type '(ctx: QueryFunctionContext<[string, string], any>) => Promise<any>' has no properties in common with type 'UseQueryOptions<any, Error, any, QueryKey>'..
If the error was the QueryKey not being correctly typed, I believe that would be an expected behavior, but Typescript is comparing the fetchFn to UseQueryOptions. I think that's the major issue here, or I'm missing something about this in your explanation.

[TkDodo]

I think this is just typescript trying out all the overloads, and if none matches, the error is a bit weird:

the complete error is:

const fetchRepo: (ctx: QueryFunctionContext<[string, string], any>) => Promise<any>
No overload matches this call.
  Overload 1 of 3, '(queryKey: QueryKey, options?: UseQueryOptions<any, Error, any, QueryKey> | undefined): QueryObserverResult<any, Error>', gave the following error.
    Type '(ctx: QueryFunctionContext<[string, string], any>) => Promise<any>' has no properties in common with type 'UseQueryOptions<any, Error, any, QueryKey>'.
  Overload 2 of 3, '(queryKey: QueryKey, queryFn: QueryFunction<any, QueryKey>, options?: UseQueryOptions<any, Error, any, QueryKey> | undefined): QueryObserverResult<...>', gave the following error.
    Argument of type '(ctx: QueryFunctionContext<[string, string]>) => Promise<any>' is not assignable to parameter of type 'QueryFunction<any, QueryKey>'.
      Types of parameters 'ctx' and 'context' are incompatible.
        Type 'QueryFunctionContext<QueryKey, any>' is not assignable to type 'QueryFunctionContext<[string, string], any>'.
          Type 'QueryKey' is not assignable to type '[string, string]'.
            Type 'string' is not assignable to type '[string, string]'.ts(2769)

the bottom lines are important: You can see that type QueryKey is taken for the queryKey (because of the missing 4th generic, QueryKey is the default value), and that doesn't match [string, string], because QueryKey is an alias for string | unknown[]

[lukemorales]

I guess there isn't much to do @TkDodo? Unfortunately things got way more verbose now for those cases, specially for useQueries with different fetch functions if they use QueryFunctionContext instead of inline approaches 😞

[TkDodo]

I’m afraid not. My advice would be to use type inference, and keep the error to unknown. Then, make a user defined type guard that narrows the type and use that, something like: if (isAxiosError(error)). This is also more safe because at runtime, there is no guarantee what your error is