I find myself having non_null calls all over my schemas. Can this be the default? For example, these snippets could be equivalent:
defmodule GraphqlSchema.Types.Alert do
use Absinthe.Schema.Notation,
non_null: true
object :alert_mutations do
field :delete_alerts, type: :deletion_result do
arg :ids, list_of(:integer)
resolve &GraphqlSchema.Resolvers.Alert.delete_alerts/3
end
end
object :alert do
field :description, nullable(:string)
end
end
defmodule GraphqlSchema.Types.Alert do
use Absinthe.Schema.Notation
object :alert_mutations do
field :delete_alerts, type: non_null(:deletion_result) do
arg :ids, non_null(list_of(non_null(:integer)))
resolve &GraphqlSchema.Resolvers.Alert.delete_alerts/3
end
end
object :alert do
field :description, :string
end
end
I suggest you create a macro to make non null fields easier in your projects.
E.g. to stick with graphql SDL syntax
arg :ids, list_of!(:integer)
Macros look like a great solution here, this would be far to significant of a breaking change...
I did not propose a breaking change, but fine.
Sorry, I didn't even notice the configuration option on use Absinthe.Schema.Notation
A few tiny macros could accomplish this with the existing syntax, so I'm not sure we'd want alter Absinthe itself to have multiple "modes" that a schema can be running under, especially since people can break up their schema definitions into many modules - that could lead to complexity if an included module is in a different "mode"... All of the schema stuff is done at compile time using module attribute accumulators, so it's fairly complex on the inside already.
Also with 1.5 you can define schemas using GraphQL SDL notation, so it'd look like this:
type Mutation {
deleteAlerts(ids: [Int!]!): DeletionResult!
}
Most helpful comment
Sorry, I didn't even notice the configuration option on
use Absinthe.Schema.NotationA few tiny macros could accomplish this with the existing syntax, so I'm not sure we'd want alter Absinthe itself to have multiple "modes" that a schema can be running under, especially since people can break up their schema definitions into many modules - that could lead to complexity if an included module is in a different "mode"... All of the schema stuff is done at compile time using module attribute accumulators, so it's fairly complex on the inside already.
Also with 1.5 you can define schemas using GraphQL SDL notation, so it'd look like this: