Provide the queryKey in error message

[arthurdenner]

Hi! 👋🏽

As one of the breaking changes on v4, the queryKey needs to be an Array. I want to report to our internal services when a non-array queryKey is provided so our microfrontends can migrate accordingly - we have 30+ of projects to update.

There's an error logged when a non-array queryKey is provided (reference) but it doesn't contain the provided queryKey. Is it possible to add it to the message?

My current solution is to override the useQuery export to check the queryKey, but I think doing it through the logger would be a cleaner solution.

Related question: useQuery doesn't throw, only logs, when a non-array queryKey is provided and it works fine, data is loaded, but other APIs such as getQueryData fail when receiving a string as queryKey, e.g.:

index.js:1341 Uncaught TypeError: Cannot create property 'exact' on string 'someQueryKey' (reference) - arg1 is the string, not falsy, therefore returned, which fails here.

Are there plans to throw an error in useQuery OR support strings in other APIs?

[TkDodo]

Is it possible to add it to the message?

I've tried, but the problem is the overloads of useQuery and how we parse arguments:

https://github.com/tannerlinsley/react-query/blob/f9ebf9aaae59050331c22f143d835e46fac402cc/packages/query-core/src/utils.ts#L104-L121

So if it's neither an array, nor a function, it will be spread, and spreading a string results in the queryKey being undefined by the time we access it.

However, now that I'm thinking about it, maybe you want to contribute to add an additional dev-only runtime check similar to this one:

query/packages/query-core/src/query.ts

Lines 353 to 359 in 357ec04

	if (!Array.isArray(this.options.queryKey)) {
	if (process.env.NODE_ENV !== 'production') {
	this.logger.error(
	`As of v4, queryKey needs to be an Array. If you are using a string like 'repoData', please change it to an Array, e.g. ['repoData']`,
	)
	}
	}

to parseQueryArgs and parseMutationArgs, that checks that if we get a string in and then logs a similar error? There, we would have access to the string then and could provide better messages.

Are there plans to throw an error in useQuery OR support strings in other APIs?

if we throw in useQuery, it will go to error state and retry. I wanted to avoid that because it hides the issue. The uncaught type error seems to be a natural follow-up bug because we have no overloads for this function, thus we don't use parseQueryArgs to normalize. It's not an intentional throwing on our side.

[arthurdenner]

Thanks for the detailed reply, @TkDodo, especially on why not to throw in useQuery.
Rethinking what I suggested before, as it was a breaking change, I think it's fine how it is today.

I decided to patch-package v3 and report non-array keys in the ensureQueryKeyArray function (reference).
Once we don't have any reports, we know we can update safely.

Unless you still prefer to add more logs, I'm fine with closing the discussion.

[Djarma12]

I was having the same error, and problem was TYPO, where i write gueryKey instead a queryKey.