-
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
v3.0.0-beta.16 mutating local state is not reflected in all components with useQuery #5733
Comments
This bug is currently eating my soul bit by bit. To escape this nightmare, I'm currently duplicating my queries so they are unique to the component. Is there a better way? |
I had a "no-duh" moment and centralized my query from my components to the parent. Sanity restored. |
@JohnBerlin, you can revert back that conditional - #5644 (comment) |
Thank you! |
Fixes #5733, which was caused by multiple watches having the same cache key, so none except the first were ever re-broadcast, since the first broadcast had the side effect of marking the later watches as clean, before this.watches.forEach had a chance to visit them. Background: PR #5644 reenabled an important optimization for the InMemoryCache#broadcastWatches method, allowing it to skip watches whose results have not changed. Unfortunately, while this optimization correctly determined whether the result had changed, it did not account for the possibility of multiple distinct consumers of the same result, which can happen (for example) when multiple components use the same query and variables via different useQuery calls. Fortunately, the fix is straightforward (if not exactly obvious): in order to assign distinct consumers different cache keys, it suffices to include the provided watch.callback function in the cache key. A more drastic way to fix #5733 would be to remove the caching of maybeBroadcastWatch entirely, which would not be a huge loss because the underlying cache.diff method is also cached. For now, though, with that backup option in mind, I'd like to preserve this optimization unless it causes any further problems.
Thanks very much to @dusty for opening this issue and providing a simple reproduction, and to @OlegLustenko for tracking down the probable cause! Please try updating to
@JohnBerlin Is that because you were trying to diagnose the bug and fix it, and you found the internals of the cache hard to understand? If so, I can definitely empathize. Not everyone understands this system as well as I do, and it's not your responsibility to find solutions like #5747. It is your responsibility, however, to remember that you're using beta software, and that we all share the same basic goals. Once you get into that mindset, I think you'll find words like "eating my soul" and "nightmare" no longer feel appropriate. Take that advice, or leave it. I'll fix the bugs either way. |
Intended outcome:
Store local state in apollo cache and when updating the local state then all components that have a useQuery against that data will be updated.
Actual outcome:
It appears only the first subscriber to the useQuery receives updates.
How to reproduce the issue:
At the following code sandbox you can see some local state stored in apollo. There are three components that are rendering the result of the same useQuery query. When the Child component calls a mutation on that data, only the Parent component updates. Both the Child component and the OtherChild component do not update.
If the query is removed from the Parent component, then only the Child component updates.
If the query is removed from both the Parent and Child, then the OtherChild component updates.
https://codesandbox.io/s/apollo-client-prob-6ywxk
Versions
The text was updated successfully, but these errors were encountered: