-
Notifications
You must be signed in to change notification settings - Fork 2k
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
incremental: lazily create DeferredFragments #4153
base: main
Are you sure you want to change the base?
Conversation
✅ Deploy Preview for compassionate-pike-271cb3 ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Hi @yaacovCR, I'm @github-actions bot happy to help you with this PR 👋 Supported commandsPlease post this commands in separate comments and only one per comment:
|
Comparing to #4150, we now annotate the |
tentative spec changes to go along with this draft implementation PR are at yaacovCR/graphql-spec#3 |
c3aacf8
to
2fe45b0
Compare
once we no longer create the deferMap, collectFields also does not need to return the newDeferUsages. we do still return a boolean if defers were encountered to update the context so that buildExecutionPlan will be called; this allows us to still skip |
3c6b5c1
to
66b9dc0
Compare
This comment has been minimized.
This comment has been minimized.
@yaacovCR Something went wrong, please check log. |
@yaacovCR The latest changes of this PR are available on NPM as Also you can depend on latest version built from this PR: |
3757ea7
to
78e9df7
Compare
This comment has been minimized.
This comment has been minimized.
@yaacovCR The latest changes of this PR are available on NPM as Also you can depend on latest version built from this PR: |
goal: avoid creating or passing around the deferMap methodology: each DeferredFragmentRecord will be unique for a given deferUsage and creationPath - we annotate the deferUsage with a "depth" property representing the path length in the response for wherever this defer is delivered. - from a given execution group path, we can derive the path for the deferredFragment for a given deferUsage by "rewinding" the execution group path to the depth annotated on the given deferUsage
78e9df7
to
60f92c0
Compare
depends on #4152
goal:
avoid creating or passing around the deferMap
methodology:
DeferredFragmentRecord
will be unique for a givenDeferUsage
and creationPath
.DeferUsage
with adepth
property representing the pathdepth
in the response for wherever thisDeferUsage
is used.ExecutionGroup
, we can derive thepath
for itsDeferredFragmentRecord
from theDeferUsage
and theExecutionGroup
path
by "rewinding" theExecutionGroup
path
to the depth annotated on the correspondingDeferUsage
.note:for performance, we now save the depth of the path on the path elements themselves. this could always be replaced by a call topathToArray
aspath.depth === pathToArray(path).length)