Dapper.GraphQL Prefer SubFields vs. SelectionSet

Looks like a pretty cool library!

Not sure if it is well known, but the ResolveFieldContext does have a SubFields property which is the fields that should be requested. It looks like that Dapper.GraphQL may have a bug in that even though a field is in the SelectionSet, it may not necessarily be allowed to be returned (due to directives mainly).

Mar 26 '18 20:03 joemcbride

Well, I think you'd know better than most :) I'll update the source to use SubFields instead.

Thanks for the contribution!

Mar 27 '18 03:03 dougrday

Nice work guys. Going to start using this today on a personal project and see how it goes. Thanks for logging the issue @joemcbride!

Mar 27 '18 14:03 benmccallum

One thing I did fail to mention is that Subfields is in the 2.0 GraphQL and not earlier versions.

Mar 27 '18 14:03 joemcbride

Another note for this change @dougrday , looks like when you upgrade to a later version of GraphQL that GraphQL.Type.Schema.ResolveType has been deprecated in favour of using the DependencyResolver property which is no longer a func but a concrete type implementing GraphQL.IDependencyResolver, so the docs/example will need to update similarly.

@joemcbride, is there a default one configured for asp.net core servicesCollection or do we just need to set the DependencyResolver to a barebones class that calls asp.net core's serviceProvider anyway?

Mar 27 '18 18:03 benmccallum

The main library is server agnostic so it does not have any dependencies on ASP.NET Core. There is a FuncDependencyResolver provided for ease of transition.

services.AddSingleton<IDependencyResolver>(
    s => new FuncDependencyResolver(type => s.GetRequiredService(type)));

Mar 27 '18 18:03 joemcbride

Nice, thanks for that. Noted.

Mar 27 '18 19:03 benmccallum

Hey @joemcbride,

I've just come into a scenario as follows which reminded me of this ticket and your mention of using context.SubFields over SelectionSet. Right now I am using SubFields, but I'm needing to do paging and so I've setup the following:

A basic connection type, based off GraphQL.Types.Relay.ConnectionType<TTo> that just gives me a totalCount property for my UI.

public class BasicConnectionType<TTo> : ObjectGraphType<object>
        where TTo : IGraphType
{
    public BasicConnectionType()
    {
        Name = $"{typeof(TTo).GraphQLName()}Connection";
        Description = $"A basic (old-school paging) connection from an object to a list of objects of type `{typeof(TTo).GraphQLName()}`.";

        Field<IntGraphType>(
            name: "totalCount", 
            description: "A count of the total number of objects in this connection, ignoring pagination."
        );

        Field<ListGraphType<TTo>>(
            name: "items",
            description: $"A list of objects of type `{typeof(TTo).GraphQLName()}`."
        );
    }
}

In my root Query class:

FieldAsync<BasicConnectionType<BookingType>>(...,
    resolve: async context =>
    {
        var fieldsRequested = context.SubFields.Keys; // ["totalCount", "items"]
        // I need whats under items, i.e. the fields on BookingType that were requested
    }
)

Basically I want to get those fields required on BookingType and pass them down to my DB query. That worked well when I was operating on the ListGraphType<BookingType>>, but now I'm wrapped in a BasicConnectionType<TTo> that SubFields list is ["totalCount", "items"]. I can do context.SubFields["items"].SelectionSet.Selections.OfType<Field>().Select(field => field.Name) (like Dapper.GraphQL seems to do in an extension method) but is it ok to use that given your comments above? Seems not, as using a directive of name @include(if: false) (booking.name) doesn't drop it out of this list, but if I use that directive on items then that is dropped from context.SubFields... hmmm... Help?! 🤣

May 23 '18 04:05 benmccallum

@benmccallum At present it is not possible to get the SubFields of the SubFields in that manor. ☹️

May 24 '18 23:05 joemcbride

Hey @joemcbride, I'm currently re-visiting this TODO and wondering... is it possible now to get the SubFields of the SubFields yet? Doesn't look like it as Field doesn't have a SubFields prop yet. Should I create an issue in the GraphQL repo, or is this just flat out impossible?

If I just use SelectionSet, it seems like it still only gives you what was asked in the query, so are you saying that directives are the only graphql feature that should would make SubFields and SelectionSet different? Or are there other cases?

Oct 10 '18 13:10 benmccallum