0.10: GraphQL typing ignores load option #1150
Description
Activity
I took a look at this but found that it's a tougher problem than I realized. GraphQL-Ruby's
loads: ...option expects a GraphQL type class, not an application class. Under the hood, GraphQL-Ruby takes the given ID, loads an object for it (GraphQL-Ruby itself doesn't know what kind of object to expect), then calls the schema'sresolve_typehook to make sure that the loaded object does in fact resolve to the configuredloads: ...type.But
def resolvereceives the application object, not the GraphQL type. In order for this to work right, we'd need a consistent way to go from a GraphQL type class (egTypes::PartyType) to the Rails class it uses under the hood (eg::Party). But GraphQL-Ruby itself never actually enforces a one-to-one mapping in this way -- it only requires an object that quacks like aTypes::PartyType.Because there's no existing basis for this one-to-one mapping, I'm not sure how this could be statically improved. I'm going to keep using one-off sigs 😖
We have a mutation with an argument that uses GraphQL's
loadsoption, which auto-fetches objects by their ID.It looks like this:
argument :party_ids, [ID], loads: Types::PartyType, as: :partiesThe type of the argument coming in to resolve is then
T::Array[Party], but the new compiler thinks they're stillT::Array[String]cc @jeffcarbs -- just an FYI, no expectation that you fix this, thanks for the work!