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