-
Notifications
You must be signed in to change notification settings - Fork 50
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
Comments
Well, I think you'd know better than most :) I'll update the source to use Thanks for the contribution! |
Nice work guys. Going to start using this today on a personal project and see how it goes. Thanks for logging the issue @joemcbride! |
One thing I did fail to mention is that Subfields is in the 2.0 GraphQL and not earlier versions. |
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? |
The main library is server agnostic so it does not have any dependencies on ASP.NET Core. There is a services.AddSingleton<IDependencyResolver>(
s => new FuncDependencyResolver(type => s.GetRequiredService(type))); |
Nice, thanks for that. Noted. |
Hey @joemcbride, I've just come into a scenario as follows which reminded me of this ticket and your mention of using A basic connection type, based off GraphQL.Types.Relay.ConnectionType that just gives me a 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 |
@benmccallum At present it is not possible to get the SubFields of the SubFields in that manor. |
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 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? |
Looks like a pretty cool library!
Not sure if it is well known, but the
ResolveFieldContext
does have aSubFields
property which is the fields that should be requested. It looks like thatDapper.GraphQL
may have a bug in that even though a field is in theSelectionSet
, it may not necessarily be allowed to be returned (due to directives mainly).The text was updated successfully, but these errors were encountered: