Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prefer SubFields vs. SelectionSet #4

Open
joemcbride opened this issue Mar 26, 2018 · 9 comments
Open

Prefer SubFields vs. SelectionSet #4

joemcbride opened this issue Mar 26, 2018 · 9 comments
Assignees
Labels

Comments

@joemcbride
Copy link

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).

@dougrday dougrday added the bug label Mar 27, 2018
@dougrday dougrday self-assigned this Mar 27, 2018
@dougrday
Copy link
Member

dougrday commented Mar 27, 2018

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

Thanks for the contribution!

@benmccallum
Copy link
Contributor

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

@joemcbride
Copy link
Author

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

@benmccallum
Copy link
Contributor

benmccallum commented Mar 27, 2018

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?

@joemcbride
Copy link
Author

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)));

@benmccallum
Copy link
Contributor

Nice, thanks for that. Noted.

@benmccallum
Copy link
Contributor

benmccallum commented May 23, 2018

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 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?! 🤣

@joemcbride
Copy link
Author

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

@benmccallum
Copy link
Contributor

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants