Table of Contents
Arguments
{ field(argument: String) }
Arguments allow you to pass specific instructions to your fields so they can be prepared and/or resolved accordingly. You can think of arguments the same as Ruby’s named arguments. In fact, you can make it pretty clear in your resolvers that the incoming argument is from the field’s arguments.
Adding Arguments
You can add arguments to fields and directives
in quite the same way you add fields to field lists, but using the argument
method.
However, arguments do not support extended block configuration.
Arguments are a light-weight version of input fields.
argument :name, :string, null: false
The current version does not support directives for arguments.
Additional Options
desc:
/description:
String
= nil
Allows documenting the argument. This value can be retrieved using introspection or during a to_gql output.
null:
Boolean
= true
Marks if the field accepts or can deliver a null value.
array:
Boolean
= false
Marks if the field accepts or can deliver an array of values.
As of now, arguments only support one-dimensional arrays.
nullable:
Boolean
= true
Marks if the array may contain null values.
full:
Boolean
= false
A shortcut to null: false, array: true, nullable: false
.
default:
Any
= nil
The default value for the argument, in case it ends up with nil
.
Using Arguments
There are several ways you can access the arguments provided to a field. The example below go over all of them:
# Assuming
field(:welcome) do
argument(:name, null: false)
end
# Using Proc
find_field(:welcome).resolve { argument(:name) }
find_field(:welcome).resolve { |name:| name }
# Using a method
def welcome
argument(:name)
end
def welcome(name:)
name
end
Argument Injection
Because of events’ callbacks, you can deliberately ask what
elements you need to run that Proc or method. Such feature is controlled by
callback_inject_arguments
and
callback_inject_named_arguments
settings.
Read more about argument injection