How to set up resolve_type for loads in 2.2?

[bmulholland]

I'm trying to upgrade to 2.2, which seems to require a resolve_type method, but I'm struggling to understand what this should be. It was working fine for us in 2.1, so I imagine there's template code (equivalent to 2.1 behaviour) that we could drop in. What is that?

This should probably also be in the docs for loads, which currently mention only roughly what's needed but not an example of how it should work.

[bmulholland]

Found the code from https://github.com/rmosolgo/graphql-ruby/pull/4678/files#diff-ca02a7189be9dc9f1c0d328028ba139f8be8da82eca96bbfccd3c098b5ad03f7L934

So a basic example would be:

  def self.resolve_type(type, _obj, _ctx)
    if type.kind.object?
      type
    else
      raise "Needs configuration"
    end
  end

[rmosolgo]

That works, but it's a hack. And there are cases where, if someone is crafty, they could use an object ID from one kind of object, pass it to an argument which uses loads:, but then it would get used as a different kind of argument. (It would still have to pass .authorized? for the configured loads: type, though.)

A better check would inspect obj and return a GraphQL type based on that. type is meant to be a hint -- sometimes it's an interface or union type, sometimes it's nil.

[bmulholland]

Does that mean we have to build our own mapping of Ruby objects to GraphQL types?

[rmosolgo]

You could set it up as a mapping, but in my own experience, inferring the type name from the class name works in most cases, for example:

type_name = "Types::#{object.class}Type" 
type_name.constantize # raises an error if it doesn't exist

So then you only have to hard-code the exceptions (or alternatively, add something like object.graphql_type to your application, etc...).

[bmulholland]

Awesome -- thank you!

[iesahin]

Note that for class hierarchies that resolve to the same GraphQL type, the above code can cause NameError issues.