useQuery: previous data unavailable to component mounting after fetch

[owlas]

Describe the bug

I might be using useQuery incorrectly: I assumed that using keepPreviousData: true would mean that the any component using a useQuery could never have undefined data once it's been fetched at least once. Since there would be data available from the first fetch.

In the example below, I can mount a component that uses a useQuery with previous data but the results show as undefined.

To Reproduce
Steps to reproduce the behavior:

1. Go to https://codesandbox.io/s/usequery-late-mount-fylqs?file=/src/index.js
2. Hit ++count
3. Hit refetch
4. See results appear with correct count (ok)
5. Hit ++count
6. See results remain with previous count (ok)
7. Hit "toggle another" to mount a second identical component
8. See second component has undefined results (shouldn't this be the previous count again?)

Once the second component is mounted you can hit "++count" and "refetch" and they'll stay in sync until you unmount the second component again.

Expected behavior
I expected all components using the same useQuery to have access to the query in the same state without having to store the useQuery in a global context.

[TkDodo]

okay, what you are doing here has to do with the queries being disabled and using refetch imperatively.

First of all, keepPreviousData is not there to make sure your data is never undefined. If you want that, supply initialData or placeholderData.

What keepPreviousData does is giving you the data of the previous query key on the same observer when the query key changes, instead of going into a hard loading state. It will also give you the isPreviousData: true flag along with it. This is mostly a feature to achieve good pagination, where, when you click the Next button, we are not unmounting the current page, but rather just disable the Next button or show a loading spinner, until the results are here. Combining it with enabled: false doesn't really do anything.

---

When you do step 5, you'll see that in the query cache, the data is still undefined (same as in step 1). It will only get data in the cache once you hit refetch (same as step 2).
So if you mount another observer - it can only see the data in the cache, which is undefined. The previous data taken from keepPreviousData only exists on a per observer level.

Hope that clears things up. I'd be interested in the use-case you are trying to solve with this approach :)

[owlas]

Thanks for the great answer! That makes sense.

Would there be any downsides to having keepPreviousData exist at the same level as the query cache rather than a per observer level? Or can that be achieved with initialData + placeholderData?

My use case is: I have two components:

1. A "control panel" with a lot of options, these together form the query key
2. the results pane, which shows the query results

The query itself is very expensive. So the user makes a bunch of tweaks to the control panel, hits run query (instead of fetching the query on every small tweak). Now I'd like the query results from that expensive query to stay in the results panel, while the user begins tweaking the controls for the next query.

Is react query a bad option in this case? It definitely feels like I'm using keepPreviousData as a kind of hack

[TkDodo]

that's a cool use-case, but I don't see why this shouldn't work. Here's how I'd model this:

• have one query with the key ["results", filter]
• disable that query as long as you have no filters
• In the control panel, the user tinkers with the options and when they hit apply:
  • you update the filter
  • this updates the query key, and will trigger a refetch
• if the user clicks apply again, the key changes and another fetch happens
• so you can totally set keepPreviousData: true on that query to keep showing the old results

but where is the second observer coming into play that also needs that previous data, that I'm not quite getting with this example.

[owlas]

thanks @TkDodo !

More detail:

• the results panel is actually composed of many distinct components.
• those components use a custom hook containing the useQuery
• one of these components (un)mounts frequently and so is missing keepPreviousData.

This is where I became surprised that the state wasn't shared across the observers (actually I didn't know about the observers, now I see what the number is in the react dev tools!)

[TkDodo]

okay so:

• you have no data in the cache for a specific query key, because it is currently fetching
• on the screen, you are displaying the previous data
• but if a new subscriber mounts while you are fetching for a query that doesn't have data in the cache yet, you are not seeing the previous data.

Does that sum it up alright?

[owlas]

Yes - slight change:

• you have no data in the cache for a specific query key, because it is currently fetching (is idle because disabled: true and refetch not called for that key yet)
• on the screen, you are displaying the previous data
• but if a new subscriber mounts while you are fetching for a query (or idle) that doesn't have data in the cache yet, you are not seeing the previous data.

Maybe there's no practical difference between the isFetching state and isIdle state from the cache's perspective

[TkDodo]

is idle because disabled: true and refetch not called for that key yet

okay, why refetch imperatively and not drive the enabled flag via local state, like the chosen filters and use enabled: Boolean(filters) )?

[owlas]

If this is getting too specific to my app and more like advice, I'm happy to move to another channel!

use enabled: Boolean(filters) )

Would that work if the reason it's disabled is that the filters are often valid but the user might not want to refetch results yet.

I'm going to share a screenshot of the app. The user selects a bunch of metrics that they want to see, you can change filters, sort config. I've decided the UX is better (untested) if the results (table + chart) don't refresh if you change e.g. a sort. That's because the user usually makes a lot of changes together (change the sort, the filters, and add a column).

So I want the chart and table to remain intact while the user starts to prepare the next query.

[TkDodo]

yep, I understand that. I usually solve that problem with a bit of state duplication, like have it in react state when you click around and do your filters, and then when you click apply / run query, I put the applied filters in the url. The useQuery hook listens to the url-state and the queryKey is built because of that, so it only changes and then runs immediately when the user clicks run query. On top of that, it gives me copyable urls as well. But your state could also be local and then lift-up-to-redux or so when you click Run query.

I think because you don't have that and work with enabled, you actually create a lot of disabled queries "too early" that will then never fetch. Like, I choose 3 metrics and 2 dimensions, I have 5 disabled queries, and then you click Run query and fetch the current one. The alternative approach solves that.

If you stick to that, I think you'd have to resort to initialData and get the "previous query" from the cache: https://react-query.tanstack.com/guides/initial-query-data#initial-data-from-cache

but you would need to somehow find the previous one. It's probably the one that fuzzily matches your query key with the highest dataUpdatedAt number.

I'm gonna close this, as it's not an issue and will transfer to a discussion. We can continue talking there of course