Lacking fragment support

[chris-nissen]

This doesn't support fragments, it seems. Would it be a hard feature to add?

[SimonCropp]

what exactly do you mean by "doesn't support fragments". my understanding of fragments is they dictate from the client side a group of fields. how would that map to the server side?

perhaps upload a small repro that show what you are trying to achieve

[chris-nissen]

Sorry, I should have been more specific. I found that navigation fields don't work with fragments. Say I have a query like this that comes into GraphQL .NET:

query($assetId: String!) {
   assets(ids: [$assetId]) {
       ...fullAsset
   }
}
fragment fullAsset on Asset {
   id
   assetType
   tag
   records {
      id
      description
   }
}

"records" is a child collection that needs to be included in the EF query. Because GraphQL.EntityFramework doesn't process fragments when it's figuring out what navigation properties to add includes for, this causes GraphQL .NET to choke when it tries to resolve the "records" field because the records haven't been retrieved with the asset. Does that make sense?

I'd like to use fragments to avoid repeating huge chunks of GraphQL in my client-side code, and fragments appear to be the recommended way to do that.

The query's fragments are available on the GraphQL .NET context, so I was playing with passing them into IncludeAppender.GetPaths and going from there, but I got stuck.

[SimonCropp]

Tbh i have not had a need to use fragments in that way, so have not invested the time in adding support.

Happy to accept a PR that adds support

[chris-nissen]

If we really need fragments, I may work on a PR.