-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
[RFC] Allow directives on variable definitions #510
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Redo of #486. Will wait discussion at the next WG meeting.
leebyron
pushed a commit
to graphql/graphql-wg
that referenced
this pull request
Aug 31, 2018
* Add myself to Attendees * Add discussion of variable definition directives See graphql/graphql-spec#510 for background: basically, is the API correct. It matches the API for directives on field argument definitions, and is (I believe) the most glaring "hole" in where we allow you to add directives.
🙌 |
leebyron
added
🏁 Accepted (RFC 3)
RFC Stage 3 (See CONTRIBUTING.md)
and removed
RFC
labels
Oct 2, 2018
9 tasks
lirsacc
added a commit
to lirsacc/py-gql
that referenced
this pull request
Jan 28, 2020
This adds language support for directives on variable definitions following graphql/graphql-spec#510. This is **only** language support so servers don't choke when receiving queries using this feature.
11 tasks
maartenvanvliet
added a commit
to maartenvanvliet/absinthe
that referenced
this pull request
Jan 11, 2021
See graphql/graphql-spec#510 Adds support for directives on variable definitions in the parser.
binaryseed
pushed a commit
to absinthe-graphql/absinthe
that referenced
this pull request
Jan 11, 2021
See graphql/graphql-spec#510 Adds support for directives on variable definitions in the parser.
This was referenced Dec 8, 2021
mattstern31
pushed a commit
to mattstern31/graphql-wg-membership-note
that referenced
this pull request
Dec 1, 2022
* Add myself to Attendees * Add discussion of variable definition directives See graphql/graphql-spec#510 for background: basically, is the API correct. It matches the API for directives on field argument definitions, and is (I believe) the most glaring "hole" in where we allow you to add directives.
anthonymedinawork
added a commit
to anthonymedinawork/py-gql
that referenced
this pull request
Jan 24, 2024
This adds language support for directives on variable definitions following graphql/graphql-spec#510. This is **only** language support so servers don't choke when receiving queries using this feature.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Redo of #486. Will wait for discussion at the next WG meeting.
This is currently implemented under a feature flag in
graphql-js
: https://github.com/graphql/graphql-js/blob/master/src/language/parser.js#L128Now that directives are gaining more widespread adoption, there have been multiple use cases I've seen where people want directives on variable definitions, but have to resort instead to adding them on the query definition with arguments.
An example of this: some query variable may only make sense for the client. As an example, if you have a local cache and you need a variable to differentiate different runs of the same query against that cahce. Or if you have a query being run with a different set of fragments, but the client code initiating that query needs to conform to the same API. The way to describe this might be:
The client could strip $client_var before persisting it to the server as
With our current set of directive locations, this would have to be implemented on the query definition like:
This version has a lot more validation that needs to happen (for instance, that the string argument provided is actually a variable defined on the query), and is more disconnected from the intention: to strip the client-only variable, you now have to visit all of the query's variables, rather than just stripping the node that explicitly has the directive on it.