Resolvers for sub fields

[TylerSiegrist]

Product

Hot Chocolate

Is your feature request related to a problem?

Resolvers are not run for properties of properties...

descriptor.Field(x => x.Foo.Bar).Resolve(ctx => "bar") // This is never run

I have a use case for it where I have several types implementing a shared interface. Depending on the implementation type, different downstream APIs should be called to fetch certain fields. I have created a minimal repository with a basic test to reproduce: https://github.com/TylerSiegrist/HotChocolate.Example.Resolver.Subfields

The solution you'd like

Resolvers are executed for properties of properties.

[michaelstaib]

I do not follow what you want to achieve. Why dont you define this on the author type? Do you want different resolvers depending on the path the execution takes?

[TylerSiegrist]

The latter is correct, which is particularly needed when we have types inheriting. In our scenario we have an Account interface with several implementations. There's a lot of available properties, so we have them organized into several objects such as "Location" which are properties on Account. For a FooAccount we may fetch most Location data from ServiceA but for a BarAccount we may fetch most data from ServiceB. Since Location is its own type, we have no way to define how to fetch individual properties of Location from the IObjectTypeDescriptor<FooAccount> level. If Location.addressType is fetched from a third API for both Account types (ServiceC) we have to define the resolver to fetch data from both (ServiceA/ServiceB) and ServiceC as we have to hydrate the entire Location object or inspect the selections within the resolver.

Being able to do descriptor.Field(x => x.Location.AddressType).Resolve(ctx => /* fetch from ServiceC */) is much simpler than having to do...

descriptor.Field(x => x.Location.AddressType).Resolve(ctx =>
{
    var location = new Location();
    if(/* check if addressType is selected */)
    {
        // Load data from ServiceC
        location.AddressType = serviceCData.AddressType;
    }
    if(/* check if any other fields are selected */)
    {
        // Load data from ServiceB
        location.Address1 = serviceBData.Address1;
        location.Address2 = serviceBData.Address2;
    }
    return location;
})

interface Account 
{
    name: String!
    sourceSystem: String!
    location : Location!
}

type Location
{
    addressType: String! // Fetched from ServiceC for all Accounts
    address1: String! // The rest of the fields are fetched from ServiceA or ServiceB
    address2: String!
    city: String!
    state: String!
    zip: String!
}

type FooAccount implements IAccount
{
    name: String!
    sourceSystem: String!
    location: Location! // Should be fetched from ServiceA+ServiceC
}

type BarAccount implements IAccount
{
    name: String!
    sourceSystem: String!
    location: Location! // Should be fetched from ServiceB+ServiceC
}

[michaelstaib]

To solve this you have to use scoped state which is inherited by child resolverS. Then do a decision based on this. You could even store a delegate in the state that represents the changed execution flow and combine it in essence with a middleware. You could I think get very close to the API you suggest. As for the core I do not see it as I would from the code expect that we would pull the field up. You are defining in the type API fields for this type only. So this would break predictability of our API.