Setting requestPolicy:cache-and-network in the client causes data to be intermittently lost

[wereHamster]

When I set requestPolicy to cache-and-network in the useQuery() calls, everything works as expected. But when I set it in the client, globally, then the component re-renders a couple times, first the data is there, but then data disappears while the urql is re-fetching. Is that expected?

Here is a log when the request policy is set globally:

{ fetching: false, stale: true, data: {…} }
{ fetching: true, stale: true, data: undefined }
{ fetching: false, stale: false, data: {…} }

And when I set it in the useQuery() call:

{ fetching: false, stale: true, data: {…} }
{ fetching: false, stale: true, data:{…} }
{ fetching: false, stale: false, data: {…} }

(note that fetching is never set true, however the data is refreshed)

In the urql-devtools I see that the query is torn down and then reexecuted. What condition causes this teardown?

[kitten]

That’s pretty odd! Do you have some details on your setup? Is the only difference where you’re passing cache-and-network and you’re not recreating the client?

[kitten]

We do have an issue template here: https://codesandbox.io/s/urql-issue-template-client-iui0o?file=/src/index.js
As soon as we find out why the behaviour is different between these two methods, then we'll probably find what we're looking for.

[wereHamster]

I'm having a hard time reproducing the problem on CSB. And what I was able to track down doesn't make any sense at all.

const [res] = useQuery({
  query: `query User {
      user {
        directoryId
        name
      }
    }`,
  })

When I include the directoryId field in the query urql loses the cache. If I remove the field from the query then it works as expected…

I have keys disabled for this type (User: () => null) in the graphcache configuration.

[wereHamster]

What strikes me as odd is that something must be actively evicting the data from the cache, right? Why else would useQuery not be able to retrieve it?

[kitten]

I'm not quite sure I'm following here. What you're describing sounds a little like you're not using Graphcache at all or are querying uncached data. So "loses the cache" is pretty confusing, because that's not a thing, so I'm afraid I have to ask for more details on what you're trying to code up here 😅

[wereHamster]

Ok, I'll give this a shot: https://codesandbox.io/s/peaceful-grothendieck-eoofk

When you navigate from home to the other page and then back to index, you see that 'data' briefly turns 'undefined'. This is caused by running two equal queries at the same time (they don't have to be in the same component though). If I remove the dedupExchange, everything works as I expect.

[kitten]

So based on the template here: https://codesandbox.io/s/peaceful-grothendieck-eoofk

I can see that you have two identical useQuery calls. This is specifically an edge case that's unsupported. Basically, when one query is fired off it's only identified by its operation.key. Firing off invariably changes the state of the cache and changes what queries are fired off.

That means when you have two identical hooks with identical inputs, then some results and requests will be deduplicated. In this case that may mean that you have a mount with both hooks, two initial requests, then you have both also start to render. When we render we re-subscribe to results for the operation. But technically, internally there's only one operation if you have two identical inputs mounted at the same time. That means that both hooks start to share results and this leads to some side-effects.

Suddenly this means that you become subject to React's timing. While both hooks get the same results, one may have expected to not get them at that specific time. This is specifically because mounting (first render) and effects in React are separate. You can basically get this to work as a workaround by removing dedupExchange. At that point both hooks will get cached results as they expect, but also double all cache requests and network requests.

Instead, it's unexpected to ever have the same operation mounted twice in React.

[kitten]

Basically, the reason why this isn’t a consideration on our part is three-fold:

• two places with the identical query shouldn’t exist. It’s unlikely that two parts of an app have the same data requirements so they should have independent custom queries. It’s pretty tempting in GraphQL to extract queries to one file or keep them separately, but they should be treated like props: as data requirements
• it’s already unlikely to have multiple queries run at the same time if data requirements are hoisted with fragments and to the page level. It’s true though that headers in Next.js and the likes are the exception
• using cache-and-nerwork everywhere is a bad default. You don’t actually want your header to update when it renders. The same may or may not go for a page, but never for a header, since it’ll react to change appropriately and never remounts.

I can look into why the state change looks a little inconsistent in React, but essentially it typically does because one query instructs the results of the other.

[wereHamster]

The reason why I set cache-and-network globally is to mimic the behaviour of traditional server-side rendered websites, where data is fetched every time the user navigates throughout the pages. I now see that cache-and-network is no different than network-only when set on a global level.

I disagree that it's an edge case to have multiple identical queries. Even if I were to write the queries inline (instead of generating them using graphql-codegen in a central place), then there is still a good chance that I'd end up with duplicates (purely because multiple independent components have similar data requirements). And my app isn't even that big or complex.

I just tried setting cache-and-network on the individual useQuery calls, but data is still lost. It is also lost when I use something like the following to force refresh the queries.

  React.useEffect(() => {
    reexecuteQuery({
      requestPolicy: 'network-only',
    })
  }, [reexecuteQuery])

What is the recommended practice in Urql to refresh data from the server?

[bombillazo]

Question on this!

• two places with the identical query shouldn’t exist. It’s unlikely that two parts of an app have the same data requirements so they should have independent custom queries. It’s pretty tempting in GraphQL to extract queries to one file or keep them separately, but they should be treated like props: as data requirements

What is then the urql approach to components that utilize the same dataset? The way I was approaching the library saw as an ad-hoc cache/request utility I could use to fetch any set of data in any component and it would manage the caching. So if I have component A and a separate component B internally sharing useQuery({ query: gqlString, variables: { ... }), I need to prop drill the data or somehow create a different query key so the data isn't messed up between components (e.g. make custom query string for each)?

• using cache-and-nerwork everywhere is a bad default. You don’t actually want your header to update when it renders. The same may or may not go for a page, but never for a header, since it’ll react to change appropriately and never remounts.

This is what @urql/exchange-request-policy solves, right?

[kitten]

@bombillazo We recognised that in many cases identical queries in multiple places are desirable. Often this occurs when data is shared in small reusable hooks, like user data. Hence, we've fixed this case and made it more intuitive, so in the latest version you shouldn't see any issues with it any longer.

For the second question, yes, exactly. We don't recommend overusing cache-and-network especially with shared queries because each time they'll be used, they'll also send another request and this isn't actually what people would like. On page-wide queries this may be fine, but with shared queries that occur repeatedly, this may create a lot of network traffic accidentally.

In general, just observe your traffic, either with the network tab or urql devtools, so you can judge for yourself what's better for your app though ,✌️

[bombillazo]

Awesome, I'll try it out, thanks for the insights!

[kitten]

Posting here again; we did eventually find a solution for this edge-case that will also improve behaviour in certain other cases 🎉 I've created a new sandbox to include the new pre-release packages to demonstrate this: https://codesandbox.io/s/modest-heyrovsky-7bnq7

You can expect this to be shipped soon 👍

[wereHamster]

That's great news! Thanks a lot 🎉