better type narrowing for initialData

[TkDodo]

when providing initialData directly on a query, the type of data is guaranteed to be TData, not TData | undefined:

const { data } = useQuery(['test'], () => Promise.resolve('test'), { initialData: 'something' })

// 🚨 Object is possibly 'undefined'.(2532)
data.toUpperCase()

TypeScript playground

ideally, we could narrow the type when initialData is provided. This only works for initialData because initialData is executed in the constructor of the query, and because it is synchronous. Also, it can only work on v4 because in v3, undefined is technically still valid for the TData generic, so we cannot remove it from the union. In v4, undefined is illegal for successful queries, so that would now work.

Keep in mind that initialData can also be a function that returns TData | undefined, so this should also narrow if the function returns TData.

It does NOT work for:

• placeholderData, because that will revert back to undefined when a query errors
• initialData being provided globally, because TS cannot know that on an instance level. It needs to be explicitly passed to useQuery.
• suspense or any other case because a query can be cancelled while it is initially fetching, in which case it will be reset to its initial state. queryClient.resetQueries also does that. Also, without network connection in the default network mode, the query will be in fetchStatus: 'paused' and will also not have data.

I guess we could potentially do this with another overload that has initialData provided and removes undefined from the result union, but we would also have do this for useQueries.
I would like to avoid having to add another generic to useQuery, as we already have four of them.

Because this is for v4, PRs should go to the beta branch please.

[kettanaito]

So whenever initialData is provided, the returned data property is never undefined?

[TkDodo]

@kettanaito yes, that is correct. cached data is never removed and initialData synchronously populates the cache. Even if you programmatically remove the query and re-render, it will be recreated with initialData. Even if the query errors, the data is still kept.

I see no scenario where data can be undefined if initialData is provided :)

[TkDodo]

Correction: select can give you undefined, but that's a separate generic. So it correctly should mean that the TQueryFnData generic can never be undefined. TData defaults to TQueryFnData and is only different if select is provided.

[henribru]

I see no scenario where data can be undefined if initialData is provided :)

You can still pass a function to initialData that returns undefined, I assume? E.g. if it gets the initial data from cache you might not have what you need in the cache. So this narrowing shouldn't apply in that case, right?

[TkDodo]

@henribru yes, but I don' see a difference between:

initialData: undefined
initialData: 'foo'

and

initialData: () => undefined
initialData: () => 'foo'

as the signature for initialData is:

initialData?: TData | (() => TData | undefined)

so, yes, to be absolutely correct: As long as initialData is set to a value of type TData or a function that returns TData, you will always have a value in the cache.

I think we would need to look at the type of initialData, and if it's a function, look at the ReturnType instead. If that does not contain undefined in the union, we can perform the narrowing on the result.

[prateek3255]

@TkDodo I'd like to work on this issue

[yss14]

I guess we could potentially do this with another overload that has initialData provided and removes undefined from the result union, but we would also have do this for useQueries.
I would like to avoid having to add another generic to useQuery, as we already have four of them.

To my knowledge using an overload-based approach is not possible with typescript at the moment (see this playground). A return type of a function can not be inferred based on whether a certain object property is set or not. This can only be solved by introducing a generic for the query options and using conditional types based on that generic for the function return type.

But maybe some typescript guru can prove me wrong :)

[prateek3255]

@TkDodo Update here, I was trying to do it via conditional types with generic but that wasn't working as expected. So I have asked a question for it on StackOverflow. And as mentioned by @yss14 even the overload based approach also doesn't seem to be working as expected. Do you have any other ideas on what else we can try out here?

[yss14]

@prateek3255 I answered your SO question :)

Here is my working playground for the useQuery hook.