Replies: 1 comment
-
I think I might have been over-complicating things. For my use-case, I can also just build the query-key differently:
That way, I can statically ignore the first two parameters and take the third one as |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I believe to know that this feature is probably on purpose, but I would like to understand more about it, because it makes it quite hard to use
infiniteQuery
with TypeScript for me.The issue
useInfiniteQuery
will give us thefetchMoreVariable
that we return fromgetFetchMore
as the last optional parameter to our fetch function (see: https://react-query.tanstack.com/docs/api#useinfinitequery)passing the query key to the fetchFn is highly dynamic and untyped, so in accordance with this recommendation from @boschni, we are mainly using arrow functions to get type safety:
but this becomes a problem if we use multiple parameters with query keys together with
useInfiniteQuery
, because we need the last element:In order to achieve this, we need to either:
args[args.length - 1]
needs to be of type number. If we have TS 4.0, we can use variadic tuples, but its still a stretch:now we are talking, and this works nicely, but we are not on TS 4.0 yet, and it's still a bit verbose :(
Possible Solution
Don't spread the query key, but just pass it along as the first argument. I know this is a breaking change, but v3 is coming, and maybe I don't fully understand the reasoning behind it, so here goes the question:
Why is the queryKey passed as variadic arguments to the fetchFn if I define it as an Array? Wouldn't this also just work:
I can still use the key if I need to, I can still use
(...key)
if I want them as separate arguments, but I can also just keep the array and ignore the key for typesafety.Beta Was this translation helpful? Give feedback.
All reactions