-
-
Notifications
You must be signed in to change notification settings - Fork 461
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(core): Update defer/stream protocol as per spec #3389
Conversation
🦋 Changeset detectedLatest commit: 8de3c3f 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 |
if (payload.pending && !result) { | ||
pending = payload.pending; | ||
} else if (payload.pending) { | ||
pending = [...pending!, ...payload.pending]; | ||
} |
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.
Initially pending will be present on the ExecutionResult, however when we have nested incremental results then the IncrementalResult will contain new pending information which we have to add to our array here so we can keep building on our result
Co-authored-by: Phil Pluckthun <phil@kitten.sh>
Summary
In the new June 2023 spec we get the introduction of
pending
on both incremental and execution results, pending contains an array of id and path.The id will be used in incremental payloads, we can then do a lookup in
pending
and find a path, the path indicates where the fragment got spread starting at the root.Another addition here is the
subPath
which can be present on an incremental payload and builds on the path we can retrieve throughid
, when deferred selection-sets are mixed with the non-deferred one this subPath will point at where we have to start merging.