Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
RFC: OneOf Input Objects #825
base: main
Are you sure you want to change the base?
RFC: OneOf Input Objects #825
Changes from 20 commits
c385058
f6bd659
39e593c
b6741c3
d17d5ec
dca3826
7e02f5a
4111476
6754e0a
7c4c1a2
bb225f7
05fde06
e8f6145
08abf49
59cb12d
c470afb
99aa5d9
691087d
7109dbc
05ab541
6a6be52
de87d2f
57e2388
5a966f2
e78d2b5
c6cd857
d106233
87d0b22
d88d62a
a810aef
a1563a9
b45c0e4
0c9830e
c4d0b50
340594e
dbccf84
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if these lines relating to variable usage pre-empt the discussion around #1059 and should be pulled from this spec change (simplifying it).
Variables must be only of the allowed type, but it seems that we should specify what that entails for all variables and types only in one place, i.e. the separate rule.
So if we currently allow variables of nullable types to be used in non-null positions and throw a field error at runtime -- which we do -we should continue to do so irrespective of isOneOf, and if/when we make the change there, that should be done in a way that covers isOneOf as well.
Encountered this while attempting to rebase graphql/graphql-js#3813
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are two arguments against this:
VariablesInAllowedPositions
is that you can use a variable for an argument, not supply the value, and get the default. But with OneOf, default values are not allowed for any fields, so treating this as the same as the general case would only be sensical if (a) we adopt the strict version of the general rule (b) we can convince ourselves that there is a real value in consistency almost for consistency's case.@oneof
directive is held to transform all of the input object's field types into non-nullable (but still not required) types. Then, these become non-nullable positions. There is a certain ambiguity as to whether the field types themselves are nullable or not. By syntax, we want to make sure older clients can leave them out, and so we define them to be nullable. But for clients aware of@oneof
, presumably we are ok to define them as non-nullable, with the caveat that there would have to be a change to theIsRequiredInputField
algorithm. Currently, an input object field is required if is of a non-null type and does not have a default value. This would have to be changed to have an additional condition, that the parent input object does not have isOneOf to be true. Note thatIsRequiredInputField
is part of graphql-js as a utility, and referenced many times in the spec, but does not form a formal agorithm.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think so? Technically all fields on a oneof are nullable, but you must specify one and it must be non-null, so this seems a very straightforward way to require that when it comes to a variable? #1059 handles non-null positions, but this is a nullable position according to the type system.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So it's a nullable type only because we want introspection to say that it's nullable because currently that's the only way of making something optional. But a null cannot be supplied, so in a sense it's by definition "a non-nullable position."
So we would then have to introduce the concept of non-nullable positions that occur when (1) the type for the position is non-nullable or (2) the containing type is oneOf, and then the general rule about matching nullable and non-nullable would have to depend on this new "position" concept rather than the type itself.
As I type this, I can see that this additional layer is a bad idea, and I appreciate the compromise that you have ended up with.
On the other hand, in GraphQL 2.0 / TreeQL, we should definitely separate optionality and nullability, and remember to change oneOf to be better defined. (It really shouldn't be the case that you cannot use null at a nullable position.)