Add transformations phase

[twist900]

Identifies input nodes with transformation metadata and applies
them to the values. These transformations can be applied to both single-value
nodes and lists of items.

New transformations can be added in the lib/transforms/ directory, like
AbsintheHelpers.Transforms.ToInteger, or within your own project,
as long as they implement the same behaviour.

Example Usage

To add this phase to your pipeline, add the following to your router:

forward "/graphql",
    to: Absinthe.Plug,
    init_opts: [
      schema: MyProject.Schema,
      pipeline: {__MODULE__, :absinthe_pipeline},
    ]

def absinthe_pipeline(config, opts) do
  config
  |> Absinthe.Plug.default_pipeline(opts)
  |> AbsintheHelpers.Phase.ApplyTransforms.add_to_pipeline(opts)
end

To define a custom transformation on a schema field:

  alias AbsintheHelpers.Transforms.ToInteger
  alias AbsintheHelpers.Transforms.Trim
  alias AbsintheHelpers.Transforms.Increment

  field :employee_id, :id do
    meta transforms: [Trim, ToInteger, {Increment, 3}]
  end

or on a list:

  field :employee_ids, non_null(list_of(non_null(:id))) do
    meta transforms: [Trim, ToInteger, {Increment, 3}]
  end

To define a custom transformation on a schema arg:

  field(:create_booking, :string) do
    arg(:employee_id, non_null(:id),
      __private__: [meta: [transforms: [Trim, ToInteger, {Increment, 3}]]]
    )

    resolve(&TestResolver.run/3)
  end

In this case, both the Trim, ToInteger, and Increment will be applied
to the employee_id field.

[mpmiszczyk]

🚳

please no - I hate this pattern.

We can use full module names in as the parameters like

        meta transforms: [AbsintheHelpers.Transforms.ToInteger]

That won't be a problem with with alias, and will help a lot with the code navigation

[twist900]

I see your point, but this is what allows us to define custom transforms directly in the project that uses this lib. See PR/module doc:

New transformations can be added in the lib/transforms/ directory, like
AbsintheHelpers.Transforms.ToIntegerTransform, or within your own project,
as long as they follow the convention. For example, you could define a new
:increment transformation tag and create a corresponding
AbsintheHelpers.Transforms.IncrementTransform to increment numeric input
values.

Maybe we can leave it until we figure out how to use dynamic meta to directly pass custom transform functions to this phase, see here

[mpmiszczyk]

I feel like you are making my point.

If I were to pass the module name (aliased), then I could define simply MyApp.Transforms.Increment and pass it there (as long at is will follow the behaviour). And I don't need to create module with "namespace" of the helpers lib.

You can not just override the module from deps - that's an compilation warning, and most apps won't build.

[twist900]

nice, updating it now 👍

[twist900]

done ✅ , I like it! thanks e2eb945

[twist900]

going to update the docs now

[twist900]

docs updated ✅

[mpmiszczyk]

I believe that's an bug

Suggested change

	apply(transform_module, :call, [input | transform_args])
	apply(transform_module, :call, [input, transform_args])

[twist900]

nice one, now fixed here ✅

[mpmiszczyk]

Should that fail if used on any different type?

Also, it will fail with 500

[twist900]

done ✅