Correct way to create a readonly observable query

[kostia1st]

I have a use case.

User can log into the app, by calling a mutation. After that we put the user account information under certain key in queryCache. That information could be also actively updated if user chooses to change their profile info etc, different reasons and scenarios.
That's on one hand.

On the other hand, we need to consume the currently logged in user from multiple places within the app. Consume, but never request. Means, if there's no data under the key, we should just get undefined, and never run any queryFn. At the same time, once user data is ever updated in a few specific places I mentioned earlier, all the consumers must receive the update. User name (or balance) was changed? Fine, rerender the components showing the user name (or balance) everywhere automatically.

To achieve this behavior on the side of consumption I used to use a useReadonlyQuery wrapper that internally runs something like

useQuery({ 
  queryKey: ..., 
  enabled: false, 
  notifyOnChangeProps: ['data'],
  placeholderData: undefined,
  retry: false,
  structuralSharing: false,
})

It worked just fine, but after updating to the latest version of react-query I started to receive error

No queryFn was passed as an option, and no default queryFn was found. The queryFn parameter is only optional when using a default queryFn.

For now, I solved it by providing a stopgap queryFn: () => undefined.

But that left me wondering if this use case is already supported by the lib directly, but I just somehow missed it?

[TkDodo]

Consume, but never request.

It’s nota query then. Put it into a global state manager like zustand or jotai or just react context if it doesn’t change often.

Sorry but if it doesn’t have a queryFn, it’s not a good fit for react-query and you’re abusing it to have some data globally available synchronously.

but after updating to the latest version of react-query I started to receive error

I plan to make this error in TypeScript, too, so please don’t rely on this pattern.

[kostia1st]

Thanks for a timely response, I really appreciate that.

On the topic, I wouldn't say I "abuse" it since

1. I'm already using react-query for all the data management, and it works perfectly well, and I am reluctant to introduce a yet another lib just for the sake of this one use-case.
2. The state I'm referring to (user profile data, along with a lot of other things) is filled not only on the client side, but on the server too (and then being hydrated on the client), and it is convenient to have just one common approach to doing such things in the app, without inventing a bicycle for each "best fitting framework" that would make me slice the app logic in multiple pieces which would increase the overall complexity, absolutely needlessly.

I don't see a problem using react-query for everything that makes sense and works - because why not? I also might need to have one or two places where I provide an actual queryFn cache actualization function, while leaving the rest of usages intact (readonly mode). Which means, "it is a query" just not always.