The complex world where suspended and not suspended queries coexist

[lukaszmakuch]

In a project I'm working on we have some queries that use suspense: true and some that use suspense: false.

We discovered that in such a setup request de-duplication behaves differently than what we expected. Some queries are fetched multiple times even though the suspended component renders just once.

This codesandbox illustrates the behavior I'm talking about - https://codesandbox.io/s/condescending-mccarthy-xpu9x?file=/src/App.js The whole App is suspended, and parameters don't change, so we'd expect a result like:

first: 1 second: 1
second: 1

Instead, we get:

first: 1 second: 2
second: 2

What means that the following queries are run twice:

const { data: second } = useQuery("second", fetchSecond, { suspense: false });

I'm not familiar with the current codebase, but I've studied the v1 version. The observed behavior is identical, so I'll assume it conceptually stayed the same.

What we observe here is that the "second" query starts before "first" "gets suspended" and then it goes stale. Because it's stale, when the components finally render without getting suspended, "second" is refetched.

It's the correct behavior if we agree that queries are the things that get suspended. However, there's another way to think about it - where components, and not individual hooks, get suspended.

If we agreed that components get suspended, and in the linked codesandbox all components appear on the screen at once, then both queries should be fetched only once.

I'd love to know your opinion about it. What is the expected behavior? Which one adheres to the Principle Of Least Astonishment?

[tannerlinsley]

Yeah this is interesting. The way it works today is all based on promise sharing between queries with identical keys. So if you have a suspense boundary that depends on a promise being resolved in react query, only to display another instance of the same query inside of it, then you are correct that this will trigger another fetch, but only if the data is stale. In that example, it technically would be no different if you weren’t using suspense. We’ve been well aware of this from the beginning and have prescribed staleTime adjustments to your query instance configs. Theoretically, if your data is changing very quickly, the second fetch would reveal new data, and likewise, if you know that’s highly unlikely, then you can and should increase the stale time regardless to match your expectation or requirements of data freshness.

[lukaszmakuch]

If there was no suspense at all, both "first" and "second" would be fetched only once. But then I'd need to manually handle loading and error states for "first".

If both "first" and "second" used suspense, they would also be fetched only once. But then it'd be slower than it needs to be (of course the codesandbox is just an example, the real app has reasons to wait for some resources and continue without others).

Just to make sure that I explained the problem clearly, I'd like to highlight the fact that in the linked example the query that's refetched more times than it needs is the one that does not use suspense.

Do you find it a path worth considering to mark queries as stale only after the components using them render?

[tannerlinsley]

Maybe it will help to describe how stale time is used. When data is fetched, it is tagged with an updated at time stamp. Stale time is not a timer that will eventually alter the state of the query, instead, it is an indicator to that particular instance how much time can pass from the updated at time stamp before the data for that particular instance is considered stale. So in practice you can actually have two query instances with different stale time thresholds that use the same data. One could be stale and one not.

[tannerlinsley]

Oh oh oh. I see what your talking about. Sorry I’ve been mobile and failed to look at the source code for the example. Hold on while I compose this reply...

[tannerlinsley]

What’s happening is that with the first useQuery, the entire component is suspended before the second can fire. This is just how suspense within the same component works for now for all tools that use it. Once a component suspends, it cannot be suspended again until that suspension resolves. So in this case, you would need to separate into two components one for each hook. I know this approach sucks... which is why in v3, we have a useQueries hook that lets you run arbitrary queries that suspend in parallel.

[lukaszmakuch]

Parallelization sounds interesting, and I'd love to dive deep into it, but for the sake of clarity in this thread I'd like to focus on when data is re-fetched.

Right now we mark queries as stale after the responses arrive. With Suspense it can happen that the same data will be fetched multiple times before some component completely renders.

What do you think about marking queries as stale not after the data arrives but after all the querying components render? That way assuming the query parameters stay the same, one change of the screen will correspond to at the most one fetch. In other words, request deduplication will work in a way more connected with the rendering, what could be considered more natural and less surprising.