v3: Remove auto-passing of query key variables to functions, replace with query context.

[tannerlinsley]

Instead of the API allowing/affording to automatically passing the query keys (spread into args) like this:

const fetchPostById = (_, _ , id) => {
  // ...
}
useQuery([userId, 'posts', id], fetchPostById)

// or

const fetchPosts = (userId, _, cursor) => {
  // ...
}
useInfiniteQuery([userId, 'posts'], fetchPosts, {
  getNextPageParam: (lastPage, pages) => lastPage.nextIndex
})

The function would simply be passed a context object, and we would update the documentation/educational material to first encourage passing an inline function, then expose users to the more powerful context-driven function parameter:

useQuery([userId, 'posts', id], () => fetchPostById(id))

// or

useInfiniteQuery([userId, 'posts'], (queryOrCtx) => {
  return fetchPosts({
    userId,
    cursor: queryOrCtx.nextPageParam
  })
}, {
  getNextPageParam: (lastPage, pages) => lastPage.nextIndex
})

Pros

• No more encouragement of patterns that result in unused variables everywhere
• Parameter count, argument types and function signature are now more predictable for both internals and users
• With a single parameter, infinite query functions no longer have to list out all of the unused queries to get to the page parameter.
• Relatively easy migration
• If users still want to abstract into a function declaration, they can still do that:

const fetchPostById = ({ queryKey: [userId, , id] }) => axios.get(`/${userId}/posts/${queryOrCtx.id}`)
useQuery([userId, 'posts', id], fetchPostById)

Cons

• Not backwards compatible

[flybayer]

I like it. Having the query key passed in as first arguments was a bit confusing and not intuitive.

[petrogad]

Agreed; I've just been creating inline functions per your example to avoid the un-used variables in my methods.

[TkDodo]

Nice, I was having the exact same problem to retrieve the cursor, and started a discussion here:
#1224

but then found an easier workaround where I put all the query params in an object, so I "only" had to exclude the first two parameters. It's still a bit annoying to get the cursor. It is also not type-safe, so with TS, we are using the inline functions all the time.

[tannerlinsley]

Your discussion sparked this idea 😉

[tannerlinsley]

Judging from the additive discussion happening in Discord, this is a very good idea. @boschni Would this be difficult to implement in v3?

[sunnysingh]

I recently started using React Query and I was very confused by the current implementation. I kept changing up my arguments until I got it right.

+1 for the context object, not only does it lower the learning curve but also cleans up the API.

[willhoney7]

This a good change and honestly probably how it should have been from the beginning.

The downside is how much code I'm going to have to update. 😕

[tannerlinsley]

Yes, there will be some breaking changes with it. In the end, I still think most people should be using inline functions with useQuery anyway :)

[sunnysingh]

Is it possible to codemod this change?

[danieljcafonso]

+1 for this. Would avoid so many eslint ignores for no-unused-vars.

Despite needing to update all the current code to adjust to this change, I think it would make everything easier for people that are starting with react query and the codebase a bit more readable from that point on.

[boschni]

Think this is a good idea! Query keys should primarily be used as a way to identify queries and to specify dependencies (these two concerns could even be split further but this might degrade the ergonomics a bit). Query parameters can be referenced in inline functions anyway and this method works great with TypeScript. A QueryContext also allows for more flexibility and fixes the cursor issue. It shouldn’t be that much work to add in v3. Was playing with the same idea after reading @TkDodo‘s discussion :)

[jaredpalmer]

This is how we do it in our internal data fetching lib at Formium which works very similarly. However, we invert the order so that it looks more like it would if we were to pass the args. We found this way easier to scan.

useResource(promise, [arg1, arg2, arg3], options)

[seloner]

the problem I faced one time was that I wanted to use the same function to fetch data for both useMutate and useQuery and I ended up coding two functions because of the key in the useQuery

[mickm77]

Happier ESLint = happier me :)

[kevinbailey25]

Already have been using inline functions to avoid unused parameters. This wouldn't effect any of my projects. I think this is a great idea.