-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
fix(useQuery): let type of queryKey for the QueryContext be inferred from the key passed to useQuery #2047
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
fix(useQuery): let type of queryKey for the QueryContext be inferred from the key passed to useQuery #2047
Conversation
…from the key passed to useQuery
…nferred from the key passed to useInfiniteQuery
|
This pull request is being automatically deployed with Vercel (learn more). 🔍 Inspect: https://vercel.com/tannerlinsley/react-query/FYbQgJGixQ14Y4boknDtGxedHgeG |
for more type safety and to make queryKeyHashFn generic as well
| .fetchOptimistic(defaultedOptions) | ||
| .then(({ data }) => { | ||
| defaultedOptions.onSuccess?.(data) | ||
| defaultedOptions.onSuccess?.(data as TData) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@boschni I went a bit down the rabbithole with that last commit (395a509), but I think types are now more exact than before. here, for example, data is inferred to TData | undefined, which is correct, and it was any before. But onSuccess expects TData, which is why I added the type assertion. I think this is the only real change - everything else is just drilling generics :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work! I didn't pursue typing the query key in v3 because it does add a lot of generics and I was not sure if people would actually use the query context. But if there is need for it then this looks good 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we merge it then? I'd like to fix types of initialData but I don't want to start until this huge type monster is merged :)
| // Create query function context | ||
| const queryKey = ensureArray(this.queryKey) | ||
| const queryFnContext: QueryFunctionContext = { | ||
| const queryFnContext: QueryFunctionContext<unknown[]> = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I needed to use unknown[] here because after ensureArray, TQueryKey is no longer true, as that contains strings as well. I think it's not a big deal, but if you know how to make ensureArray return TQueryKey if the input is an array and [string] is not, we could improve this further.
tannerlinsley
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me, but I'd like @boschni's approval as well before merging.
|
🎉 This PR is included in version 3.13.3 🎉 The release is available on: Your semantic-release bot 📦🚀 |
This PR picks up where #1955 left off and infers the QueryKey of the
QueryContextpassed to the queryFn from the actual QueryKey