Input types
In addition to object types GraphQL also supports input types. While being similar to object types, they are better suited for input data as they limit the kind of types you can use for fields.
This is how the GraphQL spec defines the difference between object types and input types :
The GraphQL Object type (ObjectTypeDefinition)… is inappropriate for reβuse (as input), because Object types can contain fields that define arguments or contain references to interfaces and unions, neither of which is appropriate for use as an input argument. For this reason, input objects have a separate type in the system.
Defining input types
In Strawberry, you can define input types by using the @strawberry.input
decorator, like this:
Then you can use input types as argument for your fields or mutations:
If you want to include optional arguments, you need to provide them with a default. For example if we want to expand on the above example to allow optional labeling of our point we could do:
Alternatively you can also use strawberry.UNSET
instead of the None
default
value, which will make the field optional in the schema:
API
@strawberry.input(name: str = None, description: str = None)
Creates an input type from a class definition.
-
name
: if set this will be the GraphQL name, otherwise the GraphQL will be generated by camel-casing the name of the class. -
description
: this is the GraphQL description that will be returned when introspecting the schema or when navigating the schema using GraphiQL.
One Of Input Types
Strawberry also supports defining input types that can have only one field set. This is based on the OneOf Input Objects RFC
To define a one of input type you can use the one_of
flag on the
@strawberry.input
decorator:
Deprecating fields
Fields can be deprecated using the argument deprecation_reason
.
This does not prevent the field from being used, it’s only for documentation. See: GraphQL field deprecation .