Can't pass a string value as the first parameter of `useQuery()`

[mw999]

Describe the bug
When passing a string as the first parameter of useQuery(), it doesn't get passed into the defaultQueryFn correctly.

To Reproduce
Steps to reproduce the behavior:

1. Create a defaultQueryFn for your QueryClient
2. Provider the QueryClient using QueryClientProvider.
3. Try and run a query with useQuery('my-endpoint')
4. See incorrect params being passed to defaultQueryFn

Expected behavior
The queryKey passed to the defaultQueryFn should be in the format [key, params], no matter if useQuery() has been passed an array, string or object as the first parameter.

const defaultQueryFn = async ({ queryKey }) => {
  const [key, params = {}] = queryKey;

  // should equal { key: 'my-endpoint', params: {} }
  // actually equals { key: 'm', params: y} }
  console.log({ key, params })
});

//

const query = useQuery('my-endpoint');

[TkDodo]

looks like a regression from here: #2074, because we've removed ensureArray

but I don't really understand why the queryKey should be an array if you don't send it in as an array? The queryKey is what the queryKey is 🤔

[mw999]

Thanks for the quick reply @TkDodo

The documentation shows this type of queryKey and defaultQueryFn usage: https://react-query.tanstack.com/guides/default-query-function#_top

I've always liked the flow of passing a string for simple queries, array syntax for a query that requires params, and object syntax for queries that require more complex configuration.

Would you recommend being consistent with the type of queryKey passed instead?

[TkDodo]

uuh, that's a good point. I think we missed updating the docs with #2074. The problem was more a typescript one. So on type-level, the queryKey was always just the queryKey, but at runtime, it was transformed to an array if it was a string. you can see a length discussion on the PR here: https://github.com/tannerlinsley/react-query/pull/2074/files#r606303577

Would you recommend being consistent with the type of queryKey passed instead?

yes, that would definitely have been my approach, or you can do a typeof runtime check in your defaultQueryFn. Sorry that our types-patch release has broken this situation for you, especially because it's shown in the docs

[dalborgo]

I've the same problem.

This is my query:

queryClient.prefetchQuery('jwt/codes', { throwOnError: true })

...and my defaultQueryFn:

export const defaultQueryFn = async ({ queryKey }) => {
  const [_key, { owner, ...params } = {}] = queryKey
  const { data } = await axiosLocalInstance(_key, {
    params,
  })
  return data
}

With 3.13.9 version, I get this request:

With 3.13.10 version, I get this one:

[JosNun]

Similar to @mw999 , this change broke stuff for me as well. I'm fine with not converting to an array by default, but the docs need to be updated, particularly here where it explicitly says that strings get converted to an array.

Skimming the conversation both here, and on the pr, it seems as if this behavior is here to stay? (debating on whether I should update now, or wait till it's confirmed that this'll be the behavior moving forward).

IMO, this should be a breaking change, since documented behavior does change. There's also at least 3 instances where this has broken things for users, and I assume more will come, or have already experienced it, and just updated their code without saying anything.

[TkDodo]

so, from what I know, it's still converted to an array internally. If you have two observers:

useQuery('myKey', ...)
useQuery(['myKey'], ...)

they will still be the same internally, share the same cache, be treated equally. You can then call e.g. queryClient.setQueryData('myKey') or queryClient.setQueryData(['myKey']) to update the one cache entry - so they are the same. I think this is what the docs are referring when it says:

useQuery('todos', ...) // queryKey === ['todos']

---

what has changed now is the injection of the queryKey into the queryFn via the QueryFunctionContext. the docs are quite vague on that:

The function that the query will use to request data.
Receives a QueryFunctionContext object with the following variables:
queryKey: QueryKey

I can see that the biggest pain points probably come from using a defaultQueryFn, because you could've expected an array to be passed into that. On type level, this is still string | unknown[].

@kachkaev @boschni do you think we should revert #2074? Or at last partially so that ensureArray is being called again, and then maybe try to find a solution on type level so that string is removed from the union once the key is passed to the QueryFunctionContext.... ?

[TkDodo]

I think I have a fix that reverts the runtime changes and keeps the good type inference. hold tight.

[TkDodo]

here it is, can you try out the codesandbox pr build maybe?

#2200

[JosNun]

Just tinkered with the CodeSandbox a bit. I can confirm that for my use case, namely, the default query function, this does restore the pre-#2074 behavior. 👍

[TkDodo]

that's good to hear. I'll wait for a review, there are some type questions hopefully @boschni can take a look at, but I'm confident we can ship it like this to revert the unintended breakage :)

[tannerlinsley]

🎉 This issue has been resolved in version 3.15.2 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀