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

feat: add experimental support for parsing fragment arguments #4015

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

JoviDeCroock
Copy link

@JoviDeCroock JoviDeCroock commented Jan 26, 2024

This is a rebase of #3847

This implements execution of Fragment Arguments, and more specifically visiting, parsing and printing of fragment-spreads with arguments and fragment definitions with variables, as described by the spec changes in graphql/graphql-spec#1010. There are a few amendments in terms of execution and keying the fragment-spreads, these are reflected in mjmahone/graphql-spec#3

The purpose is to be able to independently review all the moving parts, the stacked PR's will contain mentions of open feedback that was present at the time.

CC @mjmahone the original author

Co-authored-by: mjmahone <mahoney.mattj@gmail.com>
Copy link

netlify bot commented Jan 26, 2024

Deploy Preview for compassionate-pike-271cb3 ready!

Name Link
🔨 Latest commit e2d8d2d
🔍 Latest deploy log https://app.netlify.com/sites/compassionate-pike-271cb3/deploys/65b4097a6a6eb80008b194d7
😎 Deploy Preview https://deploy-preview-4015--compassionate-pike-271cb3.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

Copy link
Contributor

@mjmahone mjmahone left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for rebasing the syntax changes! This looks correct to me.

I'm not sure whether we need the full stack of changes up before merging any of the changes: I'd be surprised if the syntax changes need to be modified due to the validation or execution changes.

This update is probably worth bringing to the graphql-wg this week: https://github.com/graphql/graphql-wg/blob/main/agendas/2024/02-Feb/01-wg-primary.md

Copy link

Hi @JoviDeCroock, 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

@JoviDeCroock
Copy link
Author

@mjmahone worth bringing up that the PR is up, or should that be for the graphql-js wg? Not entirely sure 😅

@JoviDeCroock
Copy link
Author

CC @graphql/graphql-js-reviewers

@kitten
Copy link

kitten commented Jan 30, 2024

The implementation in this branch passes tests but uses UNSET. However, there's an alternative here: JoviDeCroock@1ee3f42, which has some updated tests.

Basically, the spec proposal uses CoerceArgumentValues (which itself is used in CoerceFieldArgumentValues, which isn't reflected in graphql-js since the spec conflates two different data structures), which is in turn used in ArgumentsFromSpread.

The spec then uses versions of spreadArgumentValues / argumentValues, i.e. a version of “variables” only for the fragment variable definitions, and keeps the variableValues separate. Since CoerceArgumentValues is reused, we should raise an error in CollectFields (via the former) for invalid values (e.g. undefined on non-defaulting non-null fields), which is reflected in the linked commit.

@mjmahone
Copy link
Contributor

worth bringing up that the PR is up, or should that be for the graphql-js wg?

I think it's worth adding a 5-10 minute dicussion item to the WG meeting this thursday https://github.com/graphql/graphql-wg/blob/main/agendas/2024/02-Feb/01-wg-primary.md

@mjmahone
Copy link
Contributor

The implementation in this branch passes tests but uses UNSET. However, there's an alternative here: JoviDeCroock@1ee3f42, which has some updated tests.

I don't think that is true anymore? I think @JoviDeCroock removed all the UNSET hacks from this PR (they might still exist in the executor changes). It also looks like graphql-js #4015 no longer uses the UNSET hack.

We should definitely ship the graphql-js changes that most closely match the changes to the spec itself, and the UNSET hack does not match the spec changes from Spec #1081 , but this looks like the parser changes are in a reasonably good state right now to my eyes!

@JoviDeCroock
Copy link
Author

JoviDeCroock commented Feb 27, 2024

@mjmahone yeah it doesn't use it it's just the parser. The execution PR also uses the new spec text

@JoviDeCroock
Copy link
Author

@graphql/graphql-js-reviewers is there anything missing to move this and the linked PR's forward?

@nandorojo
Copy link

So excited for this! Let me know if you want any help testing it in a real app.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants