graphql / graphql/graphql-spec
Missing information about keywords and whether they are reserved
- Dominant language
- JavaScript
- Stars
- 14.6k
- Forks
- 1.2k
- PR merge metrics
- No merged PRs in 30d
Description
Hello,
I have been working on new PHP implementation of GraphQL.
Specs provided all the information I needed and everything was pretty smooth - except for struggling to find information about keywords and whether they are reserved.
I started my development with tokenizer, where I followed the "Language" section and created corresponding tokens, followed by Parser which applies some higher level syntax rules - pretty standard stuff. I was struggling to decide which words are reserved keywords and which are not.
The word "keyword" is used only five times in the latest specification draft.
- First two somewhat mention the "query" keyword in paragraph about other subject, which does not make it clear at all.
- Third mentions true/false keywords for boolean type.
- Fourth mentions null keyword as null literal.
- Fifth and the last one mentions "repeatable" keyword in type system document.
I found my "working answer" by experimenting with other implementations and how they behave, but I think this should be explicitly defined in the Language section, because right now the behaviour may differ between implementations.
For example my server-side implementation allowed the word `input` or `query` to be used as argument/field name, until my colleague, who was using the API, reported that the most popular client-side implementation for C# does not allow those words to be used and I had to rename my arguments.
For simplicity, a keyword candidate is a word which has special meaning and we want it to be highlighted differently, I prepared a table of such words.
| Candidate | Document type | Usage |
|---|---|---|
| true/false/null | both | value literal |
| query, mutation, subscription | executive document | operation type |
| fragment | executive document | fragment definition |
| on | executive document | type condition |
| on | type system document | directive location definition |
| schema | type system document | schema definition |
| type, interface, union, input, enum, scalar, directive | type system document | type/directive definition |
| implements, repeatable | type system document | type/directive modifiers |
I think it is pretty standard to declare true/false/null as literals and make them reserved keywords, but I am not sure about the others. This clarification would make development of tokenizers, which are used for parsing queries, much easier and more clear. It would also unify the behaviour between different GraphQL implementations, because now some may be more tolerant than others.
Thank you.
Contributor guide
Assessment
This issue has not been assessed yet.