Skip to content

fix(react-query): update Incorrect Inference of GetDefinedOrUndefinedQueryResult when TData is assignable to CallableFunction #9278

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

ViewableGravy
Copy link

@ViewableGravy ViewableGravy commented Jun 14, 2025

Overview

This PR resolves an issue that was brought up in discord where using queryOptions where TQueryFnData was { name: string }, would cause the type of TData on useQueries to be { name: string } instead of { name: string } | undefined.

Upon further investigation into what was causing this, it looks like because InitialData is assignabled to { name: string } when it is a function (since name is a key on CallableFunction in typescript), the type would assume the wrong pathway in the GetDefinedOrUndefinedQueryResult type, resulting in the incorrect return type.

Changing the initial condition from T extends { initialData?: ... } to T extends { initialData: ... } allows us to avoid hitting that pathway altogether and gives the correct type.

Tests

I have updated the tests to ensure this case is correctly tested against, and ensured that existing tests are not affected. I have also slightly restructured the tests specifically testing queryOptions under a describe for better code organization.

Original Issue

Discord Thread: https://discord.com/channels/719702312431386674/1382540005624512532

…QueryResult when TData is assignable to CallableFunction

* Only consider the initialData pathway in GetDefinedOrUndefinedQueryResult when the key is defined

* test CallableFunction case for useQueries
@ViewableGravy
Copy link
Author

I can see that my pnpm.lock file shows a large number of changes - however I've ensured that I am using the correct version of pnpm and made sure to run pnpm install directly from the root of the project, so I am unsure why this is the case against master.

Please let me know if I should revert the lock file change, as this should not affect this PR with or without it.

Noting that running pnpm build:all also fails against vue - this change only affects react-query

@TkDodo
Copy link
Collaborator

TkDodo commented Jun 19, 2025

however I've ensured that I am using the correct version of pnpm

you were definitely using the wrong version, I can see that lockfileVersion changed:

- lockfileVersion: '9.0'
+ lockfileVersion: '6.0'

so yeah, definitely the wrong version of pnpm. Please revert, not sure why you’d even commit lockfile changes if you didn’t touch package.json 🤷

@ViewableGravy
Copy link
Author

however I've ensured that I am using the correct version of pnpm

you were definitely using the wrong version, I can see that lockfileVersion changed:

- lockfileVersion: '9.0'
+ lockfileVersion: '6.0'

so yeah, definitely the wrong version of pnpm. Please revert, not sure why you’d even commit lockfile changes if you didn’t touch package.json 🤷

Sorry about the time waste here. I just shouldn't have committed it in the first place. I've reverted that change now

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants