graphql-spec
graphql-spec copied to clipboard
Proposal: Shorthand for variables/arguments on an operation
Background
This is a very initial idea for allowing a shorthand for using/matching variables and arguments on a selection set. In many projects we (The Guild) worked with, we saw this repeating pattern of using the same name for variables and arguments.
Proposal
Today we are doing the following in order to declare a variable, and match it with an argument:
query user($id: ID!) {
user(id: $id) {
# ...
}
}
But, if the variable and the argument have the same name, we should be able to do the following:
query user($id: ID!) {
user($id) {
# ...
}
}
So if the $id is used as-is, without an explicit argument name, it will match the id argument.
I think there is no real need to provide the argument name if it's the same as the variable name, and it will simplify the usage.
This is similar to the JS shorthand while working with objects, you can do { foo } instead of { foo: foo }.
I think this kind of shorthand can be implemented by changing a few lines of code in the parser / lexer implementation: if there is a variable instead of an argument - we can just use the variable name as the argument name and the rest remains the same.
My main hesitation for this is the same as Michael raised during the WG: the syntax user($id) looks like positional arguments. This is concerning for a couple reasons:
- potentially confusing to read, particularly with people unfamiliar with GraphQL
- would prevent us adding positional arguments in future.
I'm also slightly concerned that it introduces two ways of expressing the exact same thing, giving users another thing to learn and opening questions about ASTs/etc.
I wonder if this is a task better suited to a pre-processor (kind of like CoffeeScript was to JavaScript); for example with a schema-aware preprocessor you could even omit the variable definitions:
query user {
user($id) {
# ...
}
}
and have it output our current syntax, implying the variable name and type:
query user($id: ID!) {
user(id: $id) {
# ...
}
}
Despite the above, I'm definitely interested to see where this goes.