-
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
Support options.reobserveQuery callback for mutations. #7827
Conversation
e4c9fad
to
f15f0e7
Compare
f15f0e7
to
141fcb3
Compare
describe('refetching queries', () => { | ||
itAsync('can pass reobserveQuery to useMutation', (resolve, reject) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I mentioned in #7878 (comment), I'm now thinking about supporting a standalone client.reobserveQueries(
// This callback invalidates some fields in the cache.
cache => {
// Modify the cache somehow, using writeQuery, writeFragment,
// evict, modify, etc. Anything that invalidates fields.
},
// This callback gets called for any ObservableQuery objects
// affected by the invalidation.
(observableQuery, diff) => {
// Force any affected queries to be refetched from the network.
return observableQuery.refetch();
},
); |
141fcb3
to
0774b64
Compare
0774b64
to
432e21c
Compare
@hwillson @jcreighton @brainkim I think this PR is ready for review now? I can tackle #7827 (comment) in a follow-up PR. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome @benjamn - 👍 from me! We'll want to add docs for this before we finalize 3.4 (but those can definitely be handled in a separate PR). Thanks!
432e21c
to
ac87e61
Compare
Wow, just noticed some of these commits are timestamped from August 2020. Guess I've been rebasing this branch locally for a while now! |
Building on #7819, this PR implements the
reobserveQuery
option I described in #7060 (comment), which allows mutations to override the refetching logic for any watched queries invalidated by the mutationupdate
function.The word "invalidated" is important here, since it means
reobserveQuery
will fire for any queries affected by cache writes, even if the result of the query does not end up changing. This is why it was previously difficult to make use of theINVALIDATE
sentinel object added in #6991, as reported in #7060. Usingcache.modify
andINVALIDATE
in the mutationupdate
function should work smoothly withreobserveQuery
, hopefully resolving #7060.Similar functionality is achievable using just
cache.batch
andonDirty
, soreobserveQuery
-style behavior does not absolutely require a mutation, butreobserveQuery
should greatly reduce the need for manual query enumeration after mutations, a larefetchQueries
. Also, since you can simply return aPromise
fromreobserveQuery
to make the mutation await async work, the need to useawaitRefetchQueries
should be (mostly) eliminated.As foretold in #7819, this PR continues (finishes? 🤞) the implementation of the following item from the Apollo Client v3.4
ROADMAP.md
section:updateQueries
,refetchQueries
, andawaitRefetchQueries
in a lot of cases.