simplify CollectFields for @defer and @stream
#3994
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
✅ Deploy Preview for compassionate-pike-271cb3 ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
yaacovCR
added
the
PR: polish 💅
|
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:
|
|
this PR also removes code that supports graphql/graphql-spec#1054 => as noted there, that "feature" is not necessarily desirable, and after feedback from the sub-WG, it seems like we should merge support for that later on in a separate PR. |
yaacovCR
changed the title
minimizes changes to CollectFields a la graphql#3982 but still creates a single memoized incremental field plan per list item.
robrichard
reviewed
Dec 8, 2023
|
Updated graphql/graphql-spec#1052 to reflect simplification from this PR. |
in favor of resolution at runtime this is a tradeoff of theoretical performance gain vs code simplification
robrichard
approved these changes
Dec 15, 2023
yaacovCR
changed the title
@defer and @stream
yaacovCR
added a commit
to yaacovCR/graphql-js
that referenced
this pull request
Dec 16, 2023
minimizes the changes to `CollectFields` required for incremental delivery (inspired by graphql#3982) -- but retains a single memoized incremental field plan per list item.
yaacovCR
added a commit
that referenced
this pull request
Jan 9, 2025
…erred (#4320) In the "old" duplicating version of incremental delivery, `collectFields()` was responsible for branching, and it therefore allowed processing a deferred named fragment even if that named fragment had already been visited as a regular non-deferred named fragment. One could have argued against that, as the old version had the concept of inlining, and so we could have just skipped the named fragment and considered it inlined, but chose not to do that. Now that we have an algorithm without duplication of fields, revisiting a named fragment will have no effect, as within the `buildExecutionPlan()` step, all the duplicated fields will be removed. So we can just remove the exception and go back to the version pre-incremental delivery where we always skip a visited named fragment. Note that we still only consider a named fragment to have been visited if it was not marked as deferred, because in the case of overlapping deferred and non-deferred spreads of the same named fragment, we need to visit it as the non-deferred spread to actually realize that it is non-deferred. [As an aside, looks like I made a mistake in #3994 => we would never have wanted to ignore the result of `shouldIncludeNode()` => since we are removing all ignoring of these conditions with respect to defer, this PR "fixes" that mistake as well.]
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
minimizes changes to CollectFields a la #3982 but still creates a single memoized incremental field plan per list item.
@robrichard