Controlling a JSON field in a AshGraphql query

Ash Forum Ash Questions / Help
,
1

In my resource, there is an attribute called component, backed by a JSONB column. I’d like to expose that attribute as a JSON field in AshGraphql, but I want to modify it first (converting keys from underscore_case keys to camelCase). Is there a way to modify it?

The attribute’s type is currently a custom Ash.Type module. I couldn’t figure out how to affect the GraphQL response with the callback functions within it (e.g., cast_input(), cast_stored(), dump_to_native()). It seems the callbacks only affect the interaction with the data layer, and input casting.

I notice there’s a modify_resolution DSL function available for the graphql DSL, but that’s defined at the query level, not at the field (resource) level, which is what I need.

2

This is an interesting question :smile: So, it is possible to make this work that we will need to add a new callback to AshGraphql.Type, and have you define a custom type and use that new callback, something like def to_graphql_value(constraints), ....

However, depending on what you are doing, we may be able to avoid the need for that.

If the keys are known statically, you could potentially do something like this:

defmodule MyType do
  use Ash.Type.NewType, subtype_of: :map, constraints: [
    fields: [...]
  ]

  def graphql_type(_), :my_type
end

But otherwise I think we will need to add some logic to our gql building to modify the resolution of individual fields with custom types. It is likely not a super complicated operation.

There are also ways you can do it in the short term, like making a calculation with a name like camelized_thing, and using configurations like hide_fields and attribute_names in your resource to hide one attribute and render camelized_thing as just thing in the GraphQL.

3

If the map type w/ static keys won’t work for you then we will probably need to add that new feature so you don’t need to jump through the field remapping hoops. I’d be happy to guide you through adding it, or try to get to it soon/see if someone else has time in the next few days to add it.

4

The keys are known statically for attribute in question’s map value, but there are child maps inside that are not static. Such as:

component: %{
  id: (string),
  field: (may be one of many different map schemas),
  ...
}

So above, id and field keys are known statically, but the keys in field are not.

How does defining a module that uses Ash.Type.NewType enable me to control what’s in the JSON data?

5

I’ll look into creating a calculation like camelized_thing.

1 Like
6

I think the camelized_component calculation is going to work for my needs. I was trying to make the data shape exactly like an Absinthe query that this new query is replacing, but I can manage minor incompatibilities like this.

7

You would effectively have the same problem with that nested type, and would need that same feature to control graphql representation. That is a valuable feature for us to have, so I’d like it to exist at some point, it’s just not there yet (maybe in part because calculations etc. are a workaround)

1 Like