ghostdogpr
Empty objects/enums - `_: String! = __typename` instead of `_: Boolean = null`
Sometimes a person on the client-side accidentally inserts _ into the query instead of __typename, resulting in receiving null. Would it be possible for the artificial field _ to return the same value as __typename?
"this is bad"
type Foo {
"Fake field because GraphQL does not support empty objects. Do not query, use __typename instead."
_: Boolean
}
"this is better"
type Foo {
"same as __typename"
_: String!
}
Someone accidentally using _ for __typename seems really random and not a good reason to change the behavior 🤔 Is there any reason they would do that? If that kind of convention was widely used in other graphql libraries or if there was a special reason, that could motivate a change.
Alright, this might be a bit random, but is there really a good reason to have an artificial field _: Boolean = null? Other than backwards compatibility? Either way, it’s documented as "should not be used in a query." Still, this field exists and is just a source of random errors. When you have a field foo: Foo! (notice the ! type), you can get a response with foo = null – absurd behavior. It happens regularly. Shouldn't good design prevent such mistakes? We may not be able to prevent people from using the _ field, but we can make sure that this field isn't filled with garbage. Being error-prone should be a good reason to change it
Unfortunately we can't change the type as this change is not backwards compatible and we will break the CI pipelines for all users that have schema backwards compatibility checks in place.
As for people accidentally using _ instead of __typename, I think the same issue applies for any field possible? We really can't guard against accidental usage of a field. In fact, since _ has a different type than __typename, this makes it far less error prone when using any kind of static type checking on your queries (which most if not all languages support).
A few things we could do (potentially):
- Make the
_deprecated which might(?) help with accidental usage - Add an optional validation that disallows querying the
_field. However, since no one asked for this before I'm not sure we should be incurring the additional maintenance burden on this. You could also potentially write a custom validator yourself and append it to the list of validations via theExecutionConfiguration
