Fragment arguments/variables (syntax/validation/execution)

[JoviDeCroock]

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

• Changing fragment-key to just be fragment-name Fragment Arguments Reference Implementation graphql-js#3835 (comment)
• Removing the substitution logic and going closer to the coerce logic we use in the general flow

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.

[netlify]

✅ Deploy Preview for graphql-spec-draft ready!

Name	Link
🔨 Latest commit	641e3d9
🔍 Latest deploy log	https://app.netlify.com/sites/graphql-spec-draft/deploys/66d889cf63f74b000a197201
😎 Deploy Preview	https://deploy-preview-1081--graphql-spec-draft.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

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

[mjmahone]

This is clear to me :)

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

[JoviDeCroock]

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

[benjie]

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]

@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.

[benjie]

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

[benjie]

@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 👍

[benjie]

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

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: JoviDeCroock / name: Jovi De Croock (61d2117, 6e91f98, 44aea8b, b4f3c5d, e027a4f, 210a814, b60feac, 492c556, 8be0561, cbf20d0, 548163a, 2e541bb, 562edd8, 5927fa9, 3516ca1, c46e706, 2117038, 94a0027, 21e3881, b0ac799, 16e8986, f5b3061, f306736, 815952a, a868d04, 7ecdf98, 4edb481, 0361664, 641e3d9, df27219, b07931f)
• ✅ login: mjmahone / name: Matt Mahoney (4269caf)

[benjie]

@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]

@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

[benjie]

^ Trying to get EasyCLA to re-evaluate.

[benjie]

@mjmahone Do you feel this replaces #1010? If so, I propose we close 1010 and move the RFC1 label to this PR.

@JoviDeCroock excellent work; to progress this further you should bring it to an upcoming Spec WG, and state the intent to move it from RFC1 to RFC2.

[benjie]

I think there's more subtlety that needs to be addressed during validation.

[mjmahone]

Yes this replaces #1010

[JoviDeCroock]

Update here, Implemented validation and everything, can be linked through from here

[Urigo]

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]

Changes in JoviDeCroock#1 are blocked by #1039