Fields
Fields for Object and Interface types are defined using a shape
function. This is a function that takes a FieldBuilder as an argument, and
returns an object whose keys are field names, and whose values are fields created by the
FieldBuilder. These examples will mostly add fields to the Query
type, but
the topics covered in this guide should apply to any object or interface type.
Scalars
Scalar fields can be defined a couple of different ways:
Field method
Convenience methods
Convenience methods are just wrappers around the field
method that omit the type
option.
Other types
Fields for non-scalar fields can also be created with the field
method.
Some types like Objects and Interfaces can be referenced by name if they have a backing model defined in the schema builder.
For types not described in the SchemaTypes
type provided to the builder, including types that can
not be added there like Unions and Enums, you can use a Ref
returned by the
builder method that created them in the type
parameter. For types created using a class
(Objects or Interfaces) or Enums created using a typescript
enum, you can also use the class
or enum
that was used to define them.
Lists
To create a list field, you can wrap the the type in an array
Nullable fields
Unlike some other GraphQL implementations, fields in Pothos are non-nullable by default. It is still often desirable to make fields in your schema nullable. This default can be changed in the SchemaBuilder constructor, see Changing Default Nullability.
Note that by default even if a list field is nullable, the items in that list are not. The last example above shows how you can make list items nullable.
Exposing fields from the underlying data
Some GraphQL implementations have a concept of "default resolvers" that can automatically resolve fields that have a property of the same name in the underlying data. In Pothos, these relationships need to be explicitly defined, but there are helper methods that make exposing fields easier.
These helpers are not available for root types (Query, Mutation and Subscription), but will work on any other object type or interface.
The available expose helpers are:
exposeString
exposeInt
exposeFloat
exposeBoolean
exposeID
exposeStringList
exposeIntList
exposeFloatList
exposeBooleanList
exposeIDList
Arguments
Arguments for a field can be defined in the options for a field:
For more information see the Arguments Guide.
Adding fields to existing type
In addition to being able to define fields when defining types, you can also add additional fields independently. This is useful for breaking up types with a lot of fields into multiple files, or co-locating fields with their type (e.g., add all query/mutation fields for a type in the same file where the type is defined).
To see all the methods available for defining fields see the SchemaBuilder API
Nested Lists
You can use t.listRef
to create a list of lists