-
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
feat: Allow returning IGNORE
sentinel from optimisticResponse
functions to support bailing-out from the optimistic update
#11410
feat: Allow returning IGNORE
sentinel from optimisticResponse
functions to support bailing-out from the optimistic update
#11410
Conversation
@sf-twingate: Thank you for submitting a pull request! Before we can merge it, you'll need to sign the Apollo Contributor License Agreement here: https://contribute.apollographql.com/ |
👷 Deploy request for apollo-client-docs pending review.Visit the deploys page to approve it
|
🦋 Changeset detectedLatest commit: ef08c05 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
null
from optimisticResponse
functions to bail-out from the optimistic updatenull
from optimisticResponse
functions, to support bailing-out from the optimistic update
Hi @sf-twingate 👋 Thanks for this draft PR and starting this discussion! We agree that there should be a way to bail out of an Since Since the current behavior is to always set the cache value to Would you want to implement that change in this PR and convert it out of a draft? The changes should be fairly minimal, and I'd be happy to help if you hit any blockers. Let me know - if not I'd be happy to move this over the finish line. Thanks! |
@jerelmiller @phryneas I've gone ahead and moved this out of draft against the A note on docs: I updated the Thanks for the contribution, @sf-twingate, this is ready for review 🎉 |
@@ -626,6 +633,8 @@ export class QueryManager<TStore> { | |||
invariant.error(error); | |||
} | |||
}, mutation.mutationId); | |||
|
|||
return true; |
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.
Now that I'm looking at this again, I'd vote to move the data === IGNORE
check out of markMutationOptimistic
to avoid changing the fn signature here to one that returns a boolean. Thoughts?
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.
I'd be ok with this. I'd prefer that as well 🙂
null
from optimisticResponse
functions, to support bailing-out from the optimistic updateIGNORE
sentinel from optimisticResponse
functions to support bailing-out from the optimistic update
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.
Changes are ok by me! @alessbell once you're happy with this, feel free to merge.
@sf-twingate thanks so much for the contribution!
.changeset/mighty-coats-check.md
Outdated
// conditionally bail out of optimistic updates | ||
return IGNORE; |
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.
// conditionally bail out of optimistic updates | |
return IGNORE; | |
// conditionally bail out of optimistic updates | |
return IGNORE; |
Minor nit to ensure these are aligned 🙂
@@ -626,6 +633,8 @@ export class QueryManager<TStore> { | |||
invariant.error(error); | |||
} | |||
}, mutation.mutationId); | |||
|
|||
return true; |
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.
I'd be ok with this. I'd prefer that as well 🙂
@alessbell sorry for the late response — had a busy work week and didn't yet have a chance to continue with this PR. Thank you for taking care of updating it! The changes made LGTM — just let me know if you need anything additional from my end to land this 🎉 |
…functions to bail out of update
Summary
This PR updates the behaviour of the
optimisticResponse
functional property in mutations to support returningnull
, which will cause the optimistic update to be skipped / bailed out from.This is useful to support an optimistic response only when certain variables are provided to the mutation. For example, in my use case, I only wish to perform an optimistic update when a specific variable is not included, as I can't reliably compute the result on the client when it is.
Currently, I can workaround this by writing an additional query without an
optimisticResponse
property for mutations which use this variable, and then conditionally calling one of the two mutations based on the input variables. However, this results in duplicate code and I feel this small API change would make things simpler and might be useful in other use cases.Notes
I was going to open this as an issue, but opted to write an implementation to support my request. If there's a better way of implementing this, or if the PR is missing something (new to contributing to the codebase!), just let me know and I'm happy to update it.