-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Comments
I have the same problem but from #6760 there are 2 solutions:
|
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. |
@mlarcher Exactly like |
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
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. |
@strblr Thanks to your reproduction, I'm fairly confident this issue can be resolved by updating to |
We've merged |
To illustrate the problem, here is a very simple example : Using the
network-only
policy, I fire atodos
query to get a list ofTodo
s. Then, I make each item selectable via an update mutation that takes some arguments and returns the updatedTodo
.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 thetodos
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:
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
The text was updated successfully, but these errors were encountered: