Skip to content
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

[pull] main from graphql:main #201

Merged
merged 5 commits into from
Jan 15, 2024
Merged

[pull] main from graphql:main #201

merged 5 commits into from
Jan 15, 2024

Conversation

pull[bot]
Copy link

@pull pull bot commented Nov 7, 2023

See Commits and Changes for more details.


Created by pull[bot]

Can you help keep this open source service alive? 💖 Please sponsor : )

#3984)

i.e. no fields and no enclosed deferred fragments

These fragments can be thought of to be completely skipped, because
including them will just result in emitting metadata but no actual data.
Alternatively, these fragments can be thought of as being inlined.

This could probably be considered a bug fix, in that Example F @
graphql/defer-stream-wg#69 explicitly
states that these fragments should be skipped.
Copy link

github-actions bot commented Nov 7, 2023

Hi @pull[bot], I'm @github-actions bot happy to help you with this PR 👋

Supported commands

Please post this commands in separate comments and only one per comment:

  • @github-actions run-benchmark - Run benchmark comparing base and merge commits for this PR
  • @github-actions publish-pr-on-npm - Build package from this PR and publish it on NPM

@pull pull bot added the ⤵️ pull label Nov 7, 2023
yaacovCR and others added 4 commits November 9, 2023 14:51
current loop assumes that the first analyzed DeferredFragmentRecord has been released as pending and thereofre has an `id`, which happens to be the case in this scenario, but is not reliable, uncovered by #3982.

Demonstrates the peril of `!` which might point to requiring additional types, but we can leave that for a different PR.

Another option is to include an `invariant` call -- that should be unnecessary, but would indeed be safer.
minimizes the changes to `CollectFields` required for incremental delivery (inspired by #3982) -- but retains a single memoized incremental field plan per list item.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants