Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
Tracked by #9504
strblr opened this issue Dec 16, 2020 · 7 comments · Fixed by #9504
Closed
Tracked by #9504

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

strblr opened this issue Dec 16, 2020 · 7 comments · Fixed by #9504

Comments

@strblr
Copy link

strblr commented Dec 16, 2020

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 :

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

@cgorrieri
Copy link

I have the same problem but from #6760 there are 2 solutions:

  • Forcing the version "@apollo/client": "3.0.2"
  • Set nextFetchPolicy: 'cache-first' in the useQuery but it may not be the solution for all cases.

@mlarcher
Copy link

mlarcher commented Feb 4, 2021

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 !

@strblr
Copy link
Author

strblr commented Feb 5, 2021

@mlarcher Exactly like previousData was a quick patch for a this widely unpopular PR.

@marwan38
Copy link

marwan38 commented Feb 9, 2021

I was encountering this exact issue and was able to fix it by making sure that the mutation result EXACTLY matches the query. IE: If a query asked for

query {
  Product {
    ID
    Title
  }
}

Which is quite annoying as mutation fields aren't always part of the complete query fields. This also affected the apollo internals on how it was storing the response of the mutation. I realised that it wasn't actually making an object in the store.

@hampusborgos
Copy link

hampusborgos commented Feb 9, 2022

@strblr / @mlarcher Do you know if there has been any solution to this issue? It causes significant amounts of unnecessary refetching.

Using your demo and updating to 3.5.8, problem still remains, and now TODO is not actually even checked after the reloaded query.

@benjamn
Copy link
Member

benjamn commented Apr 5, 2022

@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! 🙏

@benjamn
Copy link
Member

benjamn commented Apr 26, 2022

We've merged release-3.6 into main and released PR #9504 in @apollo/client@3.6.0 just now. That version is still tagged as next rather than latest on npm, but we will promote it to latest after some final testing. Thanks for opening this issue and for your patience waiting for the solution to land!

@benjamn benjamn closed this as completed Apr 26, 2022
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 15, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.