graphql-go

graphql-go copied to clipboard

Fixes #113.

Allows using a fragment for an interface on a field of a concrete object type. Currently this panics because the interface does not implement the concrete type, so this adds support for going the other direction when applying selections.

The approach is different than how type assertions are handled, because those need to be dynamic and figure out at runtime which concrete type is present. In this case, we know the concrete type ahead of time, so we can eagerly drop any child fragments that are on types that aren't compatible with the concrete type the original fragment was spread onto.

Hey, any progress with merging this fix? Have same problem in quite a big project...

@Alien-x and @mjm is this even allowed in the spec?

@mjm thank you for your patience with this PR! I am happy to merge it if you could resolve the conflicts, please. Would you mind doing that?

It has been three years since I opened this, I haven't kept up with the changes in the project, and I'm not still actively using this for anything. I took a quick look but the conflicts don't seem trivial, so I don't think I'll be able to do that.

@mjm That's fine. I'm going to do it. I started cleaning old issues and PRs. I'll either resolve and merge it. Or I'll pick up your unit tests and I'll make it pass. Thank you!