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.
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
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 asfield: fieldas 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
CollectFieldsorField Alias— that it's always redundant when executing a GraphQL operation.