I agree with this.
But, disagree with this as one would lose the ability to have non-null fields at all in a query response.
and also because below quote is more true:
So, I think, we should propose this:
Let the !
on fields represent that a field in the query response is non-null. Instead, provide the capability to the user to toggle the fields inside mutation inputs as non-null. This can also allow us to explicitly specify nullability for each kind of mutation input (add, update-set, update-remove). In addition, we can also allow users to be able to choose which fields they want in the addInput
vs which ones they want in the updateInput
, etc. This can be achieved with a new directive like this:
directive @input(
add: InputParams,
update: UpdateInputParams
) on FIELD_DEFINITION
input InputParams {
# defaults to false
skip: Boolean,
# defaults to
# for add inputs: whether `!` has been defined on the field in schema
# for patch inputs: false
nonNull: Boolean
}
input UpdateInputParams {
set: InputParams
remove: InputParams
}
So, now I would be able to define a schema like this:
type Note @auth(
query: { rule: "query { queryNote(filter: {isPublic: true}){ id } }" }
# ...
) {
id:ID!
text: String!
isPublic: boolean
by: Author @input(add: {nonNull: true}, update: {set: {skip: true}, remove: {skip: true}})
version: String @input(update: {set: {nonNull: true}, remove: {skip: true}})
}
which would generate following inputs:
input AddNoteInput {
text: String!
isPublic: Boolean
by: Author!
version: String
}
input SetNotePatch {
text: String
isPublic: Boolean
version: String!
}
input RemoveNotePatch {
text: String
isPublic: Boolean
}
This allows me to say things like:
- A Note’s text can’t be null in the query response.
- A Note’s author can be null in the query response.
- A Note’s author must be provided while adding the Note, but after that, you can’t update or remove the author from the note.
- A Note’s version may not be provided while adding the note, but after that, every time you update a note, you must update its version. In addition, you can’t remove a note’s version.
Later, we may extend @input
to also support default values as well like this:
type Note {
...
version: String @input(add:{default: "v0"}, update: {set: {nonNull: true}, remove: {skip: true}})
}
which allows me to say that if I don’t provide a version while adding a Note, it should default to “v0”.