TData gets incorrectly inferred in useQuery when providing both select and onSuccess

[davbrito]

Describe the bug

Say that I have a queryFn that returns type T and a select function that returns type U. If I provide a onSuccess function, TypeScript complains that select function should return type T. And the onSuccess function data parameter gets typed as T.

declare const data: T;

const query = useQuery(
  ['queryKey'],
  () => data,
  {
     select: data => data.u // Returns type "U" but TypeScript wants "T" for some reason
     onSuccess(data) { // Should be type U but is inferred as T
        console.log(data)
     }
  })

The workaround is to explicitly type the onSuccess param to be of type U.

declare const data: T;

const query = useQuery(
  ['queryKey'],
  () => data,
  {
     select: data => data.u // Works as expected
     onSuccess(data: U) {
        console.log(data)
     }
  })

Your minimal, reproducible example

https://codesandbox.io/s/serene-hofstadter-56r0r

Steps to reproduce

1. Create a query with useQuery.
2. Pass a select function that select some data with diferent type than returned by the queryFn.
3. Pass a onSuccess function and let TypeScript infer the parameter types.

Expected behavior

• The first parameter of the onSuccess should be the same as the return type of the select function.
• The TData type should be inferred with the return type of the select function.

How often does this bug happen?

Every time

Screenshots or Videos

Platform

• OS: Windows 11
• Browser: Not related because it's a TypeScript issue.

react-query version

v3.34.8

TypeScript version

v4.5.4

Additional context

No response

[TkDodo]

it's a (somewhat) known limitation that I'm unsure how to fix. useMutation has the same issue when you provide onMutate and want type inference for onSettled. There, the key is to explicitly type the input value for onMutate.

In your case, the workaround is to explicitly type the input to the select function: https://codesandbox.io/s/cranky-cohen-oc1sq?file=/src/App.tsx

related:

• (docs): add typescript example for optimistic updates #1366 (comment)
• https://tkdodo.eu/blog/react-query-and-type-script#optimistic-updates
• Proposal: Partial Type Argument Inference microsoft/TypeScript#26242

[jasikpark]

https://tkdodo.eu/blog/react-query-and-type-script#partial-type-argument-inference 🤔 I finally understand why you would want partial argument inference - at first I didn't see what the usecase would be

[HenriqueDerosa]

In my understanding, the purpose of the select is to be dynamic, allowing to customize the output of the api to be whatever we need in the front end.

Thus, select should NOT use the same return type as the onSuccess. If we want the useQuery to return the same type, we can basically omit the select.

I found out that you can actually infer the type for the select, as the link shared also exemplifies, as following:

  const { data, isLoading } = useQuery<MyResponseType, Error, string>(
    ["example query"], () => Promise.resolve(queryData),
    {
      select: (data) => data.innerData,

Please, correct if I'm wrong 🤔

[TkDodo]

I found out that you can actually infer the type for the select,

yes, you can, and that also works most of the time. react-query has 4 generics, and the 3rd one (TData) is so that select can return a different type than the queryFn ( the first generic, TQueryFnData).

However, the type inference seems to get lost as soon as you use both select and onSuccess as option. onSuccess should also get passed TData, which is the transformed / selected data.

[davbrito]

I think this is related to the problem: https://devblogs.microsoft.com/typescript/announcing-typescript-4-7-beta/#improved-function-inference-in-objects-and-methods

[TkDodo]

indeed, TypeScript 4.7 seems to fix that problem: playground link

I'll close this as an upstream issue with TypeScript.