-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
base: main
Are you sure you want to change the base?
Fragment arguments/variables (syntax/validation/execution) #1081
Conversation
✅ Deploy Preview for graphql-spec-draft ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
There was a problem hiding this 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!
5a73543
to
d7590fa
Compare
@graphql/tsc is there anything I can do to move this forward? |
There was a problem hiding this 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)
}
@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 i.e.
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. |
ac9fdbc
to
03ba255
Compare
There was a problem hiding this 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.
@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 👍 |
There was a problem hiding this 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.
|
@JoviDeCroock did you rebase on a different computer? Often this happens when |
@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 |
dc25c04
to
f306736
Compare
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 |
Changes in JoviDeCroock#1 are blocked by #1039 |
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>
@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? |
@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 |
159c1c8
to
7f384de
Compare
7f384de
to
cbf902b
Compare
808d990
to
3655fc6
Compare
3655fc6
to
0d7bc1a
Compare
Ah, damn, I just resolved a conflict this morning but another one :( |
There may be a few more in the coming days, we're merging a lot of editorial right now 😅 |
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
coerce
logic we use in the general flowIn general the biggest changes are that we introduce
fragmentVariableValues
which will be on thegroupedFieldSet
, 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.Last but not least we introduce
getArgumentValuesFromSpread
which looks at the spread and fragment-definition and establishes a coerced set of localVariableValues.