View Source Absinthe.Resolution (absinthe v1.7.5)

Information about the current resolution. It is created by adding field specific information to the more general %Absinthe.Blueprint.Execution{} struct.

In many ways like the %Conn{} from Plug, the %Absinthe.Resolution{} is the piece of information that passed along from middleware to middleware as part of resolution.

contents

Contents

  • :adapter - The adapter used for any name conversions.
  • :definition - The Blueprint definition for this field.
  • :context - The context passed to Absinthe.run.
  • :root_value - The root value passed to Absinthe.run, if any.
  • :parent_type - The parent type for the field.
  • :private - Operates similarly to the :private key on a %Plug.Conn{} and is a place for libraries (and similar) to store their information.
  • :schema - The current schema.
  • :source - The resolved parent object; source of this field.

When a %Resolution{} is accessed via middleware, you may want to update the context (e.g. to cache a dataloader instance or the result of an ecto query). Updating the context can be done simply by using the map updating syntax (or Map.put/3):

%{resolution | context: new_context}
# OR
Map.put(resolution, :context, new_context)

To access the schema type for this field, see the definition.schema_node.

Link to this section Summary

Types

The arguments that are passed from the schema. (e.g. id of the record to be fetched)

t()

Functions

Get the current path.

Get the child fields under the current field.

Get the child fields under the current field.

Handy function for applying user function result tuples to a resolution struct

Link to this section Types

@type arguments() :: %{optional(atom()) => any()}

The arguments that are passed from the schema. (e.g. id of the record to be fetched)

@type field_state() :: :unresolved | :resolved | :suspended
@type source() :: any()
@type t() :: %Absinthe.Resolution{
  acc: %{required(any()) => any()},
  adapter: Absinthe.Adapter.t(),
  arguments: arguments(),
  context: map(),
  definition: Absinthe.Blueprint.node_t(),
  errors: [term()],
  extensions: %{required(any()) => any()},
  fields_cache: term(),
  fragments: [Absinthe.Blueprint.Document.Fragment.Named.t()],
  middleware: term(),
  parent_type: Absinthe.Type.t(),
  path: term(),
  private: term(),
  root_value: any(),
  schema: Absinthe.Schema.t(),
  source: source(),
  state: field_state(),
  value: term()
}

Link to this section Functions

Link to this function

call(res, resolution_function)

View Source
Link to this function

call(function, args, info)

View Source
Link to this function

call(resolution_function, parent, args, field_info)

View Source

TODO: Deprecate

Get the current path.

Each Absinthe.Resolution struct holds the current result path as a list of blueprint nodes and indices. Usually however you don't need the full AST list and instead just want the path that will eventually end up in the result.

For that, use this function.

examples

Examples

Given some query:

{users { email }}

If you called this function inside a resolver on the users email field it returns a value like:

resolve fn _, _, resolution ->
  Absinthe.Resolution.path(resolution) #=> ["users", 5, "email"]
end

In this case 5 is the 0 based index in the list of users the field is currently at.

Get the child fields under the current field.

See project/2 for details.

Get the child fields under the current field.

example

Example

Given a document like:

{ user { id name }}
field :user, :user do
  resolve fn _, info ->
    child_fields = Absinthe.Resolution.project(info) |> Enum.map(&(&1.name))
    # ...
  end
end

child_fields will be ["id", "name"].

It correctly handles fragments, so for example if you had the document:

{
  user {
    ... on User {
      id
    }
    ... on Named {
      name
    }
  }
}

you would still get a nice and simple child_fields that was ["id", "name"].

Handy function for applying user function result tuples to a resolution struct

User facing functions generally return one of several tuples like {:ok, val} or {:error, reason}. This function handles applying those various tuples to the resolution struct.

The resolution state is updated depending on the tuple returned. :ok and :error tuples set the state to :resolved, whereas middleware tuples set it to :unresolved.

This is useful for middleware that wants to handle user facing functions, but does not want to duplicate this logic.

Link to this function

result_error(value, field, source, guess)

View Source