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