Unable to observe cache with QueryObserver (v3)

[kael]

I'm trying to observe, from a component, data fetched and cached by another component, but I can't make it work.

Upon authentication, the <Auth/> component fetches the user profile and keeps it into a cache:

  const { data: profile } = useQuery(
    "profile",
    () => fetchUserProfile(oauthz.token),
    {
      enabled: !!oauthz?.token,
      refetchOnWindowFocus: false,
      refetchOnReconnect: false,
      refetchOnMount: false,
      staleTime: Infinity,
    }
  );

A <Profile/> component is observing the cache and ready to display the profile userId:

import React, { useEffect, useState } from "react";
import { QueryClient, QueryObserver } from "react-query";

const queryClient = new QueryClient();

export default function Profile() {
  const [profile, setProfile] = useState();

  useEffect(() => {
    const observer = new QueryObserver(queryClient, {
      queryKey: "profile",
    });

    const unsubscribe = observer.subscribe((result) => {
      console.log("Profile observer", result);
      setProfile(result.data);
    });
    return () => {
      unsubscribe();
    };
  }, []);

  return <div>Profile: {profile?.userId}</div>;
}

But it's not working:

1. No result.data is received by the 'profile' cache observer in the <Profile/> component.

2. The logs display an odd (unexpected ?) error message:

{
    "status": "error",
    "isLoading": false,
    "isSuccess": false,
    "isError": true,
    "isIdle": false,
    "dataUpdatedAt": 0,
    /* Notice the Error 👇 */
    "error": "Missing queryFn",
    "errorUpdatedAt": 1644698192425,
    "failureCount": 4,
    "isFetched": true,
    "isFetchedAfterMount": true,
    "isFetching": false,
    "isRefetching": false,
    "isLoadingError": true,
    "isPlaceholderData": false,
    "isPreviousData": false,
    "isRefetchError": false,
    "isStale": true
}

Error message:

Missing queryFn react_devtools_backend.js:4061

21:36:25.382 Profile.js:22 Profile observer {status: 'loading', isLoading: true, isSuccess: false, isError: false, isIdle: false, …}
21:36:25.401 Profile.js:22 Profile observer {status: 'loading', isLoading: true, isSuccess: false, isError: false, isIdle: false, …}
21:36:26.402 Profile.js:22 Profile observer {status: 'loading', isLoading: true, isSuccess: false, isError: false, isIdle: false, …}
21:36:28.403 Profile.js:22 Profile observer {status: 'loading', isLoading: true, isSuccess: false, isError: false, isIdle: false, …}
21:36:32.425 Profile.js:22 Profile observer {status: 'error', isLoading: false, isSuccess: false, isError: true, isIdle: false, …}
21:36:32.426 react_devtools_backend.js:4061 Missing queryFn
overrideMethod @ react_devtools_backend.js:4061
onError @ query.js:356
reject @ retryer.js:67
(anonymous) @ retryer.js:132
Promise.catch (async)
run @ retryer.js:116
(anonymous) @ retryer.js:149
Promise.then (async)
(anonymous) @ retryer.js:145
Promise.catch (async)
run @ retryer.js:116
(anonymous) @ retryer.js:149
Promise.then (async)
(anonymous) @ retryer.js:145
Promise.catch (async)
run @ retryer.js:116
(anonymous) @ retryer.js:149
Promise.then (async)
(anonymous) @ retryer.js:145
Promise.catch (async)
run @ retryer.js:116
Retryer @ retryer.js:156
fetch @ query.js:330
executeFetch @ queryObserver.js:199
onSubscribe @ queryObserver.js:40
subscribe @ subscribable.js:16
(anonymous) @ Profile.js:21
invokePassiveEffectCreate @ react-dom.development.js:23487
callCallback @ react-dom.development.js:3945
invokeGuardedCallbackDev @ react-dom.development.js:3994
invokeGuardedCallback @ react-dom.development.js:4056
flushPassiveEffectsImpl @ react-dom.development.js:23574
unstable_runWithPriority @ scheduler.development.js:468
runWithPriority$1 @ react-dom.development.js:11276
flushPassiveEffects @ react-dom.development.js:23447
(anonymous) @ react-dom.development.js:23324
workLoop @ scheduler.development.js:417
flushWork @ scheduler.development.js:390
performWorkUntilDeadline @ scheduler.development.js:157
21:36:42.335 profile.js:27 Fetch finished loading: GET "https://service.com/api/profile".
fetchUserProfile @ profile.js:27
enabled @ Navbar6.js:139
fetchFn @ query.js:298
run @ retryer.js:95
Retryer @ retryer.js:156
fetch @ query.js:330
executeFetch @ queryObserver.js:199
setOptions @ queryObserver.js:85
(anonymous) @ useBaseQuery.js:78
invokePassiveEffectCreate @ react-dom.development.js:23487
callCallback @ react-dom.development.js:3945
invokeGuardedCallbackDev @ react-dom.development.js:3994
invokeGuardedCallback @ react-dom.development.js:4056
flushPassiveEffectsImpl @ react-dom.development.js:23574
unstable_runWithPriority @ scheduler.development.js:468
runWithPriority$1 @ react-dom.development.js:11276
flushPassiveEffects @ react-dom.development.js:23447
performSyncWorkOnRoot @ react-dom.development.js:22269
(anonymous) @ react-dom.development.js:11327
unstable_runWithPriority @ scheduler.development.js:468
runWithPriority$1 @ react-dom.development.js:11276
flushSyncCallbackQueueImpl @ react-dom.development.js:11322
flushSyncCallbackQueue @ react-dom.development.js:11309
batchedUpdates$1 @ react-dom.development.js:22387
(anonymous) @ notifyManager.js:75
Promise.then (async)
scheduleMicrotask @ utils.js:322
flush @ notifyManager.js:74
batch @ notifyManager.js:30
dispatch @ mutation.js:159
(anonymous) @ mutation.js:96
Promise.then (async)
execute @ mutation.js:95
mutate @ mutationObserver.js:83
(anonymous) @ useMutation.js:41
(anonymous) @ Navbar6.js:204
invokePassiveEffectCreate @ react-dom.development.js:23487
callCallback @ react-dom.development.js:3945
invokeGuardedCallbackDev @ react-dom.development.js:3994
invokeGuardedCallback @ react-dom.development.js:4056
flushPassiveEffectsImpl @ react-dom.development.js:23574
unstable_runWithPriority @ scheduler.development.js:468
runWithPriority$1 @ react-dom.development.js:11276
flushPassiveEffects @ react-dom.development.js:23447
(anonymous) @ react-dom.development.js:23324
workLoop @ scheduler.development.js:417
flushWork @ scheduler.development.js:390
performWorkUntilDeadline @ scheduler.development.js:157

And the data appears in the cache:

What am I missing ?

---

Env:

"dependencies": {
  "react": "^17.0.2",
  "react-query": "^3.34.15"
}

[TkDodo]

The easiest way to observe a query is by far useQuery, because it creates an observer under the hood. An observer also needs a queryFn to work - the error you are getting is because you are not providing one to the observer.

[bnert]

@TkDodo I am running into (possibly) something similar as @kael.

For my use case I am needing to watch as set of "dynamic" queries (i.e. queries which are provided an id to fetch a resource) which are made based on data fetched from the server. This is currently not working with either QueryObserver or QueriesObserver or a specific key or a key prefix.

For instance, I have an dependent query situation like so:

function useDevice(id) {
  return useQuery(
    ["devices", id],
    () => getDeviceById(id) // Assume returns an object
  )
}

function useDeviceIds() {
  const client = useQueryClient()
  return useQuery(
      "deviceIds",
      () => getAllDevicIds(), // Assume returns and array of ids
      {
        onSuccess: (ids) => client.invalidateQeuries(ids.map(id => ["devices", id]))
        refetchInterval: 5000
      }
    )
}

function useDevices() {
  const client = useQueryClient()
  const observer = new QueriesObserver(client, { scope: "devices" }) // Don't know if this should be "scope" or "queryKey"
  const [devices, setDevices] = useState([])
  useEffect(() => {
    // Currently, the results are always in a failed state.
    return observer.subscribe(results => setDevices(results))
  }, [client])
  return devices
}

This currently is not working and is returning the same "missing queryFn", even thought the docs here: https://react-query.tanstack.com/guides/migrating-to-react-query-3#queryobserver, do state that queries can be watched without providing a queryFn.

I can provide more context of this use case or a more flushed out code snipped if you like!

[TkDodo]

An observer needs a queryFn, because if there is no data in the cache yet, the observer wants to trigger a fetch.

Again, an observer is created when you do useQuery or useQueries. I have not seen a legit use-case for react application authors to create observers manually. You should just useQuery. Manually creating observers is mainly for lib authors to create abstractions like useQuery, e.g. for other frameworks like vue, svelte or solid.

What you want is likely:

function useDevices() {
  const deviceIds = useDeviceIds()
  return useQueries(deviceIds.data?.map(id => ({
    queryKey: ["devices", id],
    queryFn: () => getDeviceById(id)
  })) ?? [])
}

if you want to share the config with useDevices, you can extract it to a function that returns a config object:

function deviceConfig(id) => ({
    queryKey: ["devices", id],
    queryFn: () => getDeviceById(id)
})

You can then use that in both functions:

function useDevice(id) {
  return useQuery(deviceConfig(id))
}

function useDevices() {
  const deviceIds = useDeviceIds()
  return useQueries(deviceIds.data?.map(deviceConfig) ?? [])
}

[bnert]

@TkDodo, thanks for the code snippet, that clears things up for me!

[mendrik]

I think this is suboptimal, if there is a global query dictionary it would be nice to be able to observe queries at the same scope.
I handle for example my analytics out of the react context because they, in the end of the day, just push stuff to windows.dataLayer.
If a mutation succeeds or fails triggers a new GA event. Now the only way to do this seems to be adding to useMutation onError/onSuccess to every single case.

This is not only repetitive but should be unnecessary to start with.

[chikunov]

I have not seen a legit use-case for react application authors to create observers manually.

Here is an example: we have a lazy-loading tree of folders and a table, showing the content of the current folder. Something similar to Windows explorer. The tree is virtualized because it can be huge. Also, there is a resolution logic that resets you to a correct node if the one you tried to access is invalid (i.e somebody deleted it meanwhile or your direct link url is outdated).

In such setup we have to separately handle fetching and subscriptions.
So first we do all resolutions and loading logic and then create subscriptions for currently active nodes in the tree.

[erickjth]

Hey guys,

I am running into a similar situation as well. in my case, I have multiple queries with different keys based on some sort of UI filter, but I have a place in the app where I need to read all of the cache histories and merge into a big one. I used the useQuery with queryFn and it looks to work, but I feel this is not properly right. Is there a good way to achieve this?

For more context, in the onSuccess hook, I am setting the single key cache to merge all of the data based on diff filter keys, and then the app reads this single to get all the history I mentioned above.

Thanks.

[themagickoala]

An observer needs a queryFn, because if there is no data in the cache yet, the observer wants to trigger a fetch.

@TkDodo we have a use case where a parent component fires a list query e.g. useCommentsQuery(), and pushes data for each comment returned into the cache separately, which lets us get that with e.g. useCommentQuery(id). This doesn't require a queryFn because we assume the data already exists in the cache. Is there a reason this would be an antipattern? I don't really want to have to code in queryFns for individual comments that will never be called by the application.

[TkDodo]

if the queryFn isn't called, you wouldn't get that error. Most likely, you try to "read" from the cache, but it also triggers a background refetch because the data is considered stale. Have you set a staleTime for your query ?

Is there a reason this would be an antipattern?

I see no reason to create a separate cache entry that should just return data from a cache that must be previously filled and dies if it wasn't filled. That's an implicit dependency. If you move a component that has useCommentQuery(id) somewhere else into a component tree where the cache wasn't filled, it will fail. If the query is gargabe collected because of inactivity, it will fail. Lots of unhandled edge case.

You'd be better off just putting the data in react context - at least that would be an explicit dependency injection.

Of, you just leverage select to grab data from your list query by id. That's what I would do :)

[themagickoala]

As I was reading through your response I actually thought "This seems like a case for select!" It's fiddly though because the parent is an infinite query. I guess we could play around with it and see what works, otherwise, like you say, an explicit dependency via context might be better.

[TkDodo]

oh yeah, select and infinite queries is a beast 😅. It works at runtime but typings are meh. I hope to finally get to fix that in v5

[shakedlokits]

I see from the responses here that the maintainers are conflicted with the user requests. I want to observe a possible request that might or might not go out. And get it's data in a different part of the app.
Is there a way to do it?

[TkDodo]

I want to observe a possible request that might or might not go out. And get it's data in a different part of the app.

I don't understand this question, sorry. What do you mean with "that might or might not go out"? It's always easier to ask for help by describing the concrete problem you're actually facing, something like: "I have invoice data that I need to show in my app, and it should only fetch when ..." or whatever it is.

https://tkdodo.eu/blog/how-can-i

[bladeSk]

I also need this kind of functionality. To give you another use case, let's say we have data for various users:

useQuery({ queryFn: async () => Math.random(), queryKey: [ 'getUserData', { userId: 1 } ] })
useQuery({ queryFn: async () => Math.random(), queryKey: [ 'getUserData', { userId: 2 } ] })

The app might invalidate either a single user's data:

queryClient.invalidateQueries({ queryKey: [ 'getUserData', { userId: 1 } ] })

...or all users' data:

queryClient.invalidateQueries({ queryKey: [ 'getUserData', {} ] })

I need an observer that would notify me about changes to data of any user. I tried QueryObserver:

new QueryObserver(queryClient, { queryKey: ['getUserData'] }).subscribe(console.log)

But this doesn't work, QueryObserver complains about missing queryFn and no events are fired. Maybe QueryObserver is not the right tool for the job, but as far as I can tell, the only way of doing what I need, is to use queryCache.subscribe and manually filtering all the events, which is not great, because I can't leverage the powerful system of QueryKeys.

[TkDodo]

subscribing to the QueryCache is the way if you need that. you can filter the events and look at the passed query.queryKey. matching can still be done because we export the matchQuery function that we also use internally to achieve fuzzy query key matching.

[bladeSk]

Thanks for the hint. It's much more elegant with matchQuery. I believe this might be the solution for the previous comments and for the question OP asked as well.

let unsubscribe = queryClient.getQueryCache().subscribe((event) => {
  if (
    event.type === 'updated'
    && event.action.type === 'invalidate'
    && matchQuery({ queryKey: ['getUserData'] }, event.query)
  ) {
    console.log('userData invalidated', event)
  }
})

[AriaFallah]

In my case I wanted to subscribe to data for a specific query (so I could put it in localstorage without messing around with the much more complex persisters https://tanstack.com/query/latest/docs/react/plugins/persistQueryClient) and ran into the same issue where QueryObserver seemed to need a queryFn. This was undesirable because I only wanted to interact with cached data and not trigger fetches.

The solution is similar to what @bladeSk posted above, and I'm thankful to him for demonstrating the paradigm

let unsubscribe = queryClient.getQueryCache().subscribe((event) => {
  if (
    event.type === 'updated' &&
    event.action.type === 'success' &&
    matchQuery({queryKey: yourQueryKey}, event.query)
  ) {
    console.log(event.action.data)
  }
})

[TkDodo]

with the much more complex persisters

PersistQueryClientProvider is a drop-in replacement for QueryClientProvider - can you elaborate what's complex about it? I'm showing an example on how to do that in this LearnWithJson episode.

You can also try the new experimental createPersister that we shipped in v5: https://tanstack.com/query/v5/docs/react/plugins/createPersister

Both these abstractions allow you to not need to subscribe to the queryCache directly, because that's quite low-level and where the actual complexity lies :)

and ran into the same issue where QueryObserver seemed to need a queryFn

disabled observers technically don't, so pass enabled: false if you just want to "read" data.

[AriaFallah]

Thanks for taking the time to respond and maintaining react-query :)

can you elaborate what's complex about it

Maybe we have different definitions of complexity, but you keep linking things that require installing a dependency and learning a new API surface that's nontrivial. Maybe even watching a video to fully get how to use it.

because that's quite low-level and where the actual complexity lies

I think we fundamentally hold different opinions on this. It's much easier to build something small that fits your own needs on top of a low level primitive vs. figure out how to wrangle an abstraction that wasn't made for your needs.

disabled observers technically don't, so pass enabled: false if you just want to "read" data.

Hmm interesting. Would it be functionally equivalent to my code snippet above or would there be a difference? It'd be nice to include this in the docs. The fact that something called "observer" performs a side effect (fetching) is really unintuitive (even though I know this is what powers useQuery).

[TkDodo]

hat require installing a dependency

that's pretty much only because we are in a monorepo and ship different packages to npm. it's technically not different than having it all in one dependency and having different import paths like from '@tanstack/react-query/persist'. Just a different packaging / distribution approach.

learning a new API surface that's nontrivial

I'd argue that queryClient.getQueryCache().subscribe is the more complex api surface that you'd need to learn because its definitely not intended to be used in user-land. The low-level query cache apis we expose are to build adapters on top of it and to allow for other libs (like the devtools) to use them. I've never used the manual subscription api or an explicit QueryObserver in an app.

I think we fundamentally hold different opinions on this. It's much easier to build something small that fits your own needs on top of a low level primitive vs. figure out how to wrangle an abstraction that wasn't made for your needs.

Yes, seems like it. Agree to disagree 👍

Would it be functionally equivalent to my code snippet above or would there be a difference

No, it wouldn't. Cache subscriptions get a lot more events.