Behavior of onSuccess and idea for callbacks

[razgraf]

First of all, amazing tool 🙏. I've been useQuery-pilled a while back and have been using it heavily ever since.

---

Some context first: I'm implementing an architecture that leverages useQuery but uses Zustand as a state store.
I've had two use-cases where the behavior of onSuccess was a bit confusing. I'm mostly wondering if the following are too implementation specific or could somehow make their way into the official development roadmap.

No onSuccess if the cache has been pre-populated (Next, SSR)

The onSuccess callback doesn't fire when data has been passed by the server to the cache through hydration. This makes is so (when we reach the client) we don't have a clear signal for "hey, there's data in the cache, do something with it" if we want to use this success callback to direct that new data to the zustand store.

We can resolve this shortcoming by using the {data, error} variables returned by the hook itself, instead of using the callbacks. Storing data will now be decided by a follow-up useEffect.

If I understand correctly, onSuccess should get triggered whenever something is being queried, regardless of it being against the network or the cache. I'm not entirely sure why on this occasion, the callback remains silent.

No onNetworkSuccess callback

Because the architecture I've mentioned relies on an external store for state management, I'd like to direct data from useQuery into that store after it has been fetched. Therefore, I rely on a signal from the query that data is ready to be processed and added to the store.

Doing this natively in onSuccess will unfortunately overwrite the store over and over again. That's because (as mentioned above) this callback gets triggered regardless of the query being against the network or the cache.

Naturally, the need for a callback that gets called when a network request is fulfilled arises.

---

Are there some better ways of dealing with these two use-cases?
Is it maybe worth documenting the difference between handling data updates between callback and returned values in the official docs?

[TkDodo]

onSuccess is tied to the query function being run, which doesn't happen on hydration. Generally, I'd consider it an anti-pattern to copy data from react-query into a different store. If you want that, doing it with useEffect is probably best. Or, you subscribe globally to the queryCache.

But generally, why do you want to move data to zustand?

[razgraf]

Thanks. Is there a way to trigger a query's onSuccess method externally? Having it perform a request over the cache (that's presumably there after hydration).

To answer your question, I usually keep data in react-query as a store itself, but for this specific one I went with a separate state manager. I'm querying for entities over which I'll perform by-the-second local updates (the app is mimicking a real-time money stream).

Mostly tried to separate concerns: querying in one place, data storage and updates in another. I reckon I could've used react-query's mutations system for this as well, but it felt more appropriate to organize everything in a separate place. This also makes it easier to understand where data is being sourced from in the app. If other data libraries start being used in the repository, the state wouldn't be tightly linked to one of them (here react-query).

[TkDodo]

I would setup a subscription to the queryCache then and sync it there:

const queryCache = useQueryClient().getQueryCache()

useEffect(() => {
  return queryCache.subscribe(event => {
    // check event.type for things you're interested in
  })
}, [queryCache])