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

Redundant field aliases identical to field names #1035

Open
kitten opened this issue Jul 17, 2023 · 0 comments
Open

Redundant field aliases identical to field names #1035

kitten opened this issue Jul 17, 2023 · 0 comments

Comments

@kitten
Copy link

kitten commented Jul 17, 2023

This is something that's been on my mind for a while, and I reckon, the easiest way for me to forget about it and clarify this little quirk would make me finally forget about it.

The relevant part of the grammar are

Alias :
Name :
Field
Alias(opt) Name Arguments(opt) Directives(opt) SelectionSet(opt)

Hence, it's legal to write field: field, i.e. define an alias that matches the field's name but is redundant.

In the reference implementation this currently of course parses as a valid alias with the value "field" and a name "field". When printed, this is preserved as field: field as well.

In other words, it's only implied that an alias identical to a field name is redundant and hence I believe it may be beneficial to add a non-normative note stating this to be the case.

Stating that the alias can be discarded if it's equal to the field name may obviously have negative ramifications when anyone relies on how the reference implementation prints GraphQL documents (although, arguably, the spec currently also doesn't state how normalised this representation should be, so maybe it's unnecessary to worry about this)

However, imho, it might be beneficial to clarify in such a non-normative note — either near CollectFields or Field Alias — that it's always redundant when executing a GraphQL operation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant