Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a continuation of the work done by @sam-swarr in #1141 to support parameterized fragments. This PR adds the ability to pass arguments to fragment spreads. For example,
Parameterized fragments are a prerequisite for encapsulation. Without encapsulation fragments are context dependent. This makes them difficult to compose into larger selection sets or to reuse in more than one operation.
In my opinion each fragment spread (not inline fragment) should create a new isolated scope. However, this would be a breaking change. I think a good compromise is to allow opting-in to isolated scopes by adding variables to a fragment. Each parameterized fragment would create a new isolated scope and fields within that fragment cannot use variables outside that fragment's scope.
The following is an example of transforming a document that contains parameterized fragments into a spec compliant document that can be parsed by GraphQL servers.
If the queries are statically analyzable then this transformation can be applied at compile time. If this transformation was applied to the above example the result would be,