Skip to content

Fragment arguments/variables (syntax/validation/execution) #1081

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

Open
wants to merge 37 commits into
base: main
Choose a base branch
from

Conversation

JoviDeCroock
Copy link
Member

@JoviDeCroock JoviDeCroock commented Feb 16, 2024

This spec contains amendments to #1010, a diffed view is available at mjmahone#3.

These amendments are made from comments on the implementation PR and alterations from the new implementation

In general the biggest changes are that we introduce fragmentVariableValues which will be on the groupedFieldSet, these are derived from the arguments in scope of the fragmentDefinition where this field is used.

We introduce localFragmentVariables which as we are traversing down fragment-spreads are a coerced set of variables i.e.

query($b: String!, $c: String!) {
  field3(b: $b) ## uses b from variable-values
  ...A(a: "A", b: "B")
}

fragment A($a: String!, $b: String!) on X {
  field(a: $a) ## uses $a from localVariableValues
  field2(c: $c) ## we have access to variableValues so we take c from there
  ...B(b: $b) ## uses $b from localVariableValues
}

fragment B($b: String!) on X {
  ## This fragment has access to $b and $c but not to $a
  field4(b: $b) ## uses $b from localVariableValues
}

Last but not least we introduce getArgumentValuesFromSpread which looks at the spread and fragment-definition and establishes a coerced set of localVariableValues.


Copy link

netlify bot commented Feb 16, 2024

Deploy Preview for graphql-spec-draft ready!

Name Link
🔨 Latest commit 0d7bc1a
🔍 Latest deploy log https://app.netlify.com/projects/graphql-spec-draft/deploys/68664a72dff42b00082eff7e
😎 Deploy Preview https://deploy-preview-1081--graphql-spec-draft.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 project 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.

This is clear to me :)

Very excited to see progress, and thank you for cleaning up and clarifying the PR!

@JoviDeCroock JoviDeCroock force-pushed the fragment-args-2024-amendments branch from 5a73543 to d7590fa Compare March 8, 2024 07:04
@JoviDeCroock
Copy link
Member Author

@graphql/tsc is there anything I can do to move this forward?

Copy link
Member

@benjie benjie left a comment

Choose a reason for hiding this comment

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

It feels like section 2 should comment on the fact that shadowed variables may not be referenced implicitly by child fragment spreads. (This is probably not the right way of saying that!) E.g. in the following query, Forbidden is spread inside of F and attempts to use variable $a which is ambiguous, and hence not permitted.

query Q($a: Int!, $b: Int!) {
  ...F(a: 7)
}
fragment F($a: Int!) {
  ...Fine
  ...Forbidden
}
fragment Fine {
  b: echo(input: $b)
}
fragment Forbidden {
  a: echo(input: $a)
}

@JoviDeCroock
Copy link
Member Author

JoviDeCroock commented Mar 27, 2024

@benjie from a purely technical perspective I agree, I was approaching that more from a backwards compatibility perspective. The Fragments variables are only applicable within the context of a FragmentDefinitiion so we don't carry nested values. A fragment is always looked at in isolation and not from a call-stack point of view.

i.e.

query ($a: String!) {
  operation {
    ...fields(a: 'some-value')
  }
}

fragment fields($a: String) on Type {
  field(x: $a) ## this carries 'some-value'
  ...moreFields
}

fragment moreFields on Type {
  field2(x: $a) ## this would carry the value passed into the operation
}

This also makes Fragment-Arguments easier to reason about for me atleast as it's either the Variables passed into the definition or from the operation itself.

@JoviDeCroock JoviDeCroock force-pushed the fragment-args-2024-amendments branch from ac9fdbc to 03ba255 Compare March 27, 2024 13:39
Copy link
Member

@benjie benjie left a comment

Choose a reason for hiding this comment

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

I haven't got as far as section 6 yet.

@benjie
Copy link
Member

benjie commented Mar 27, 2024

@JoviDeCroock Ah! I thought we landed on the other side with this one, this does simplify things significantly because we can look at fragments in isolation 👍

Copy link
Member

@benjie benjie left a comment

Choose a reason for hiding this comment

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

Great work Jovi! Here's a few comments, but this was only a quick review so it's not exhaustive.

Copy link

linux-foundation-easycla bot commented May 17, 2024

CLA Signed

The committers listed above are authorized under a signed CLA.

@benjie
Copy link
Member

benjie commented May 20, 2024

@JoviDeCroock did you rebase on a different computer? Often this happens when git is configured to use a different email address on one computer than another, so some commits don't match EasyCLA whilst others do.

@JoviDeCroock
Copy link
Member Author

JoviDeCroock commented May 20, 2024

@benjie I did not, the commits it points at are code-suggestions I applied so maybe it's not good at the co-authored ones? Not sure 😅 can rebase to fix it

@JoviDeCroock JoviDeCroock force-pushed the fragment-args-2024-amendments branch from dc25c04 to f306736 Compare May 20, 2024 08:53
@Urigo
Copy link

Urigo commented Aug 12, 2024

For those who has a production use case for this, wants to use it and provide feedback, feel free to reach out to @the-guild-org and test it with our support using Yoga Server

@JoviDeCroock
Copy link
Member Author

Changes in JoviDeCroock#1 are blocked by #1039

JoviDeCroock added a commit to graphql/graphql-js that referenced this pull request Sep 6, 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#1081. 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.

- [execution changes](JoviDeCroock#2)
- [TypeInfo & validation
changes](JoviDeCroock#4)
- [validation changes in
isolation](JoviDeCroock#5)


CC @mjmahone the original author

---------

Co-authored-by: mjmahone <mahoney.mattj@gmail.com>
Co-authored-by: Yaacov Rydzinski <yaacovCR@gmail.com>
@leebyron leebyron added 📄 Draft (RFC 2) RFC Stage 2 (See CONTRIBUTING.md) and removed 💡 Proposal (RFC 1) RFC Stage 1 (See CONTRIBUTING.md) labels Mar 6, 2025
@leebyron
Copy link
Collaborator

leebyron commented Jul 2, 2025

@JoviDeCroock some significant changes have landed (including #1039) -- do you want to do a main merge to bring this PR up to date?

I'm also curious what remaining changes are necessary within GraphQL.js (beyond just making the flag to enable it default-on) to align to the spec?

@JoviDeCroock
Copy link
Member Author

JoviDeCroock commented Jul 2, 2025

@leebyron This might take me a while to get rebased 😅 I'll try my best when I find time.

GraphQL.JS is up to date with the spec in v17.

EDIT: the merge was a bit more straight forward than initially anticipated so I probably missed a few things, I'll go over the changes in a bit. One problematic part can be found here - getting back into this is a bit hard after a year, I might need to re-do this change completely instead or go through everything that got merged

@JoviDeCroock JoviDeCroock marked this pull request as draft July 2, 2025 06:55
@JoviDeCroock JoviDeCroock force-pushed the fragment-args-2024-amendments branch 3 times, most recently from 159c1c8 to 7f384de Compare July 3, 2025 09:05
@JoviDeCroock JoviDeCroock force-pushed the fragment-args-2024-amendments branch from 7f384de to cbf902b Compare July 3, 2025 09:07
@JoviDeCroock JoviDeCroock force-pushed the fragment-args-2024-amendments branch from 808d990 to 3655fc6 Compare July 3, 2025 09:16
@JoviDeCroock JoviDeCroock force-pushed the fragment-args-2024-amendments branch from 3655fc6 to 0d7bc1a Compare July 3, 2025 09:16
@JoviDeCroock JoviDeCroock marked this pull request as ready for review July 3, 2025 19:39
@JoviDeCroock
Copy link
Member Author

Ah, damn, I just resolved a conflict this morning but another one :(

@benjie
Copy link
Member

benjie commented Jul 4, 2025

There may be a few more in the coming days, we're merging a lot of editorial right now 😅

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
📄 Draft (RFC 2) RFC Stage 2 (See CONTRIBUTING.md)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Parameterized fragments
7 participants