-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Optional v. Nullable input redux #872
Comments
I like this "no change" approach - handling the issue with conventions; maybe you could write it up as a named specification in the same way that Relay wrote up their specifications? Then you can encourage the various GraphQL libraries/clients to add support for your specification. Does it need any special handling for lists / lists-of-lists? |
No, maybe just more examples. Calling out that any value is a valid default value, including |
I'm using Based on #542 (comment): type Mutation {
updateContact(
id: ID!,
firstName: String! @optional,
lastName: String! @optional,
birthday: LocalDate @optional,
phoneNumbers: [String!] @optional
): Contact!
}
That's still backward-compatible.
|
This is great proposal and I am going to experiment little bit and implement it in my server implementation. I see one possible problem, if this proposal (maybe sometime in the future) tried to be part of the official specs. There is a standard that spec-declared directives appear in the Introspection (as displayed by the deprecated and specifiedBy directive) as fields. In Introspection both Arguments and InputFields are represented as One possible solution would be declaring that EDIT: After re-reading specific sections in the specs, I realized that arguments can also be omitted. Please correct me if I am wrong. In this case I agree that specs should be more explicit and clear about default/omitted values. |
An alternative proposal for the often requested (#476, #542) ability to distinguish optional inputs from nullable inputs. It doesn't propose any change to core GraphQL, just conventions and directives.
It can be summarized as:
null
.Directives
Usage
Type!
Type! = value
Type @optional
Type @required
Type = null
Type
Descriptions
Type!
Works as always.
Type! = value
Already supported, just needs more documentation and encouragement. It may come as a surprise in this forum, but many developers don't know that an input can have a default, or that a default alone makes it optional.
length(unit: LengthUnit = METER): Float
. UsingLengthUnit!
would make the example clearer.Type @optional
The client knows that the service doesn't want an explicit
null
.Type @required
The client knows that the service doesn't want an omitted input. Arguably this use case doesn't exist organically; it's for those who want to return an error on principle.
Type = null
Already supported; presumably it's not common because it appears pointless. But it has an important point in this context: guaranteeing to the client that omission and explicit null behave identically.
Type
Works as always, but with a different implication. Clients can infer that omission and explicit nulls have different semantics, otherwise one of the other options should have been chosen. A partial update mutation is the typical example, but this is common in queries as well. Consider filter predicates like
(equal: String, contains: String, ...)
.null
is likely a valid input toequal
, and omission indicates to not filter. Whereascontains
is likely being forced to be nullable, and could be annotated with@optional
instead.The text was updated successfully, but these errors were encountered: