Apollo Client 3 reloading query after mutation update

[danfernand]

Hello Apollo team. We have an existing app that we are migrating from Apollo Client 2 to 3. We noticed an issue that is affecting our upgrade. After an apollo mutation modifying an entity that previously a query has loaded we are noticing we are setting loading to true if the fetch policy is set to cache-and-network.

We use cache-and-network to guarantee that our app is up to date with the backend and expect the cache to be updated with the network silently.

I am not sure if the behavior is expected since its different than AC 2.

Below I have created 2 code sandboxes that are updating a graphql server created with FaunaDB to show the issue.

Apollo Client 3 - https://codesandbox.io/s/funny-https-zb1hf

Apollo Client 2 - https://codesandbox.io/s/ecstatic-cori-t42ce

When updating completed by selecting the opposite value from a todo the whole page is reloading due to using loading from the query to show a loading state.

Both codesanbox examples are using the same graphql server.

I looking all over to confirm that this AC3 behavior is expected but cannot find anything to that regard.

Thank you for your time.

PS. Great job on the ecosystem! Once we get past this its gonna be awesome!

[hauxir]

experiencing the same issue

[kure-]

I'm experienced something similar, that might be connected to your behaviour. It feels like an errorneous behaviour of the cache. Your mutation is returning data on the response of the request. The query fetchPolicy is set to cache-and-network. The response of the request is automatically taken to write the data to cache and after that write a refetech is triggered and it should not happen. Rather than that, the cache should be updated and the component just rerender with fresh data and loading state is not set to true.

The core problem is probably the same in my situation. My mutation is not responding with data. Instead of that, I'm just using simple refetchQueries with an array of two query names. The problem here is, that those two queries contain some of the refs of other queries, and those other queries are not part of the refetch array. Those other queries are called within mounted components with queries with fetchPolicy also set to cache-and-network.
So what was working in version 2.6.something is, that mutation was called, after it was completed, two network requests have been called, cache has been updated and components were rerendered. The other components, that were using some of the refs of the two queries that were refeteched, were just rerendered with fresh data. No other network requests were made.
The main problem is, that right now, instead of 2 queries that should be refetched, i'm having like 5 or more network requests triggered. Some of them even twice :)

[benjamn]

@danfernand One of the things that changed in AC3 is that cache-and-network really means to read from the cache and make a network request, not just the first time, but whenever there's a cache update that affects this query.

Although I have a specific recommendation to achieve your desired behavior (verified using your reproduction—thanks!), there's a bit of history here that I think is worth understanding. PR #6221 was a big refactoring (released in -beta.46) that made FetchPolicy enforcement more consistent, and restored the -and-network part of cache-and-network, as described above. Realizing that this might not be the behavior folks actually want, we implemented (what we thought was) a clever trick to fall back to cache-first after the first network request, in PR #6353. This behavior was still in place when we released 3.0.0, but post-launch feedback convinced us to revert that PR in #6712, because modifying the options.fetchPolicy that you requested can be surprising and is not universally appropriate. In other words, your reproduction is making unwanted network requests because cache-and-network is being enforced literally.

However, PR #6712 did more than just revert #6353, because cache-and-network-followed-by-cache-first still seems like a very common hybrid policy that people may want to implement. To make that behavior easier to achieve, we also introduced options.nextFetchPolicy (available in @apollo/client@3.1.0), so you can specify an initial fetch policy (via options.fetchPolicy, as before) and also request a different fetch policy next time.

Long story short, if you use options.nextFetchPolicy as follows, I believe you can get the behavior you're looking for:

export default function Todos() {
  const { loading, error, data } = useQuery(GET_ALL_TODOS, {
    fetchPolicy: "cache-and-network",
    nextFetchPolicy: "cache-first",
    variables: {
      _size: 10
    }
  });
  ...
}

This means the very first query will read from the cache and make a network request, but subsequent queries will make a network request only if the cache data has become incomplete.

[danfernand]

Thank you for your response! Will give nextFetchPolicy a whirl! Apollo has made using graphql amazing. Great job!

[kure-]

thanks @benjamn , adding nextFetchPolicy seems to be working just well. The behaviour seems to be quite the same as in Apollo version 2 with fetchPolicy: cache-and-network 👍

[twittwer]

I added the nextFetchPolicy: "cache-first" to a watchQuery.
This watchQuery was updated by a mutation with optimisticResponse & update function.
After adding the nextFetchPolicy the eatchQuery doesn't emit the optimistic change anymore.

Did someone experience something similar or can point me in the right direction?