Skip to content
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

Proposal: Shorthand for variables/arguments on an operation #889

Open
dotansimha opened this issue Sep 29, 2021 · 1 comment
Open

Proposal: Shorthand for variables/arguments on an operation #889

dotansimha opened this issue Sep 29, 2021 · 1 comment
Labels
💭 Strawman (RFC 0) RFC Stage 0 (See CONTRIBUTING.md)

Comments

@dotansimha
Copy link
Member

dotansimha commented Sep 29, 2021

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.

@leebyron leebyron added the 💭 Strawman (RFC 0) RFC Stage 0 (See CONTRIBUTING.md) label Dec 2, 2021
@benjie
Copy link
Member

benjie commented Dec 2, 2021

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:

  1. potentially confusing to read, particularly with people unfamiliar with GraphQL
  2. 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
💭 Strawman (RFC 0) RFC Stage 0 (See CONTRIBUTING.md)
Projects
None yet
Development

No branches or pull requests

3 participants