[network-only] Unwanted query refetch after mutation breaks user experience

To illustrate the problem, here is a very simple example : Using the network-only policy, I fire a todos query to get a list of Todos. Then, I make each item selectable via an update mutation that takes some arguments and returns the updated Todo.

Intended outcome: When firing the update mutation on an item and getting an updated response back, it should just quietly update the corresponding Todo in the cache, and trigger a rerender for the todos query. As it did in Apollo Client 2.

Actual outcome: It does rerender the list, yes. However, it also triggers a complete refetch of todos, which is totally unwanted and considerably damages the user experience.

This is actually a major issue in some of my projects that I have to update for my clients. I just cannot migrate to version 3 and after a bit of research, I found some seemingly related topics (revolving around cache-and-network though) but none of the proposed solutions worked in my case :

• https://github.com/apollographql/apollo-client/issues/6760
• https://github.com/apollographql/apollo-client/issues/7068
• https://github.com/apollographql/apollo-client/issues/7105

How to reproduce the issue:

• CodeSandbox Link Click on one of the checkboxes, and watch as the first spinner activates under the updated item. This is the loading state of the update mutation. When it finishes, the global spinner on the list activates. This is the loading state of the todos query. Should not happen.

Versions @apollo/client: ^3.3.6 => 3.3.6

[mlarcher]

It seems indeed that many other issues are related to the one highlighted here. There is a deep issue affecting many users for version after 3.0.2, by triggering unwanted and counterproductive network requests. nextFetchPolicy is a quick patch that won’t cut it in the long run, as using it to set cache-first as recommended in many other issues prevents all future network requests for the query, even legit ones that we would want to have. Please @benjamn give this issue some love, it needs it badly !

[benjamn]

@strblr Thanks to your reproduction, I’m fairly confident this issue can be resolved by updating to @apollo/client@3.6.0-beta.10 or later (for example), thanks to PR #9504 (which applies to all results broadcast from cache updates, not just fetchMore results). Please try running npm i @apollo/client@beta when you have a chance @hampusborgos @marwan38 @mlarcher @cgorrieri! 🙏