-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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 returnPartialData for watched queries again. #4743
Conversation
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.
Excellent - thanks for bringing this back @benjamn!
packages/apollo-client/src/core/__tests__/QueryManager/index.ts
Outdated
Show resolved
Hide resolved
Thanks to @hwillson for catching this! #4743 (comment)
7374bb6
to
f823b5f
Compare
PR #1370 inexplicably removed support for a useful feature: the ability to opt into receiving partial results from the cache for queries that are not fully satisfied by the cache, by passing the returnPartialData:true option to client.watchQuery. This feature is especially important in conjunction with React (or any other view framework Apollo integrations that use client.watchQuery), since it can prevent rerendering undefined data just before fetching a larger query over the network. A lot has changed since PR #1370 was merged in March 2017. The author and reviewer of that PR no longer work for Apollo, and I would like to believe that our current development culture would prevent us from ripping out such a useful feature without providing a meaningful replacement.
These tests were removed by PR #1370. A lot has changed since March 2017, but fortunately the same general concepts still apply, and the tests pass with minor adjustments.
f823b5f
to
21916e0
Compare
@@ -250,10 +250,6 @@ export class LocalState<TCacheShape> { | |||
return forceResolvers; | |||
} | |||
|
|||
public shouldForceResolver(field: FieldNode) { | |||
return this.shouldForceResolvers(field); | |||
} |
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.
@hwillson Do you think it's safe to remove this method if we're not using it internally?
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.
@benjamn Yes, for sure!
I am sooooooo incredibly excited about this PR! Just to call this PR out for those that have notifications enabled on this repo - currently, if you run a query like: const GET_MEMBER = gql`
query GetMember($id: ID!) {
member(id: $id) {
id
name
}
}
`; in one component, the results are cached, then you run a superset query like the following in another component: const GET_MEMBER_WITH_PLANS = gql`
query GetMemberWithPlans($id: ID!) {
member(id: $id) {
id
name
plans {
id
title
duration
}
}
}
`; Apollo Client will not re-use the partial data that was cached from the first query, when it preps and displays the second component. It can't find a cache hit for the full second query, so it fires the full query over the network. After this PR (and after we add in related |
Hi @benjamn - thank you for taking the time to add this. We've had an issue with it however. We were unaware of the re-implementation and when updating to I'm unsure if this was an intended change that Thank you. |
PR #1370 inexplicably removed support for a useful feature: the ability to opt into receiving partial results from the cache for queries that are not fully satisfied by the cache, by passing the
returnPartialData: true
option toclient.watchQuery
.This feature is especially important in conjunction with React (or any other view framework Apollo integrations that use
client.watchQuery
), since it can prevent rerenderingundefined
data just before fetching a larger query over the network.A lot has changed since PR #1370 was merged in March 2017. The author and reviewer of that PR no longer work for Apollo, and I would like to believe that our current development culture would prevent us from ripping out such a useful feature without providing a meaningful replacement.