feat: Add support for better fragment type resolution

[budde377]

This PR adds improved support for fragment resolution by introducing a new map to lookup type relationship

Take the document:

fragment FAuthor on Author {
  __typename
  id
}
fragment FAudience on Audience {
  __typename
  id
  numHands
  isClapping
}
fragment FUser on User {
  id
  __typename
  name
}
query {
  users {
    ...FAuthor
    ...FAudience
    ...FUser
  }
}

and the schema

type Query {
  users: [User]
}

interface User { 
  id: ID!
  name: String
}

type Author implements User {
  id: ID!
  name: String
  numBooks: Int
}

type Audience implements User {
  id: ID!
  name: String
  numHands: Int
  isClapping: Boolean
}

the current implementation will fail to realize which fragment spreads apply to a given type. E.g. that FUser and FAuthor should apply to the Author type. This leads to partial results on fragments and wrong results on inline fragments. By adding some introspection in the shape of the possibleTypeOf lookup map, which maps object types to possible interfaces and unions, we can resolve this.

If the map is omitted, or if the __typename is omitted, this solution will not expand any fragments. This is sound. The current approach expands all fragment spreads and only expands on exact matches for inline fragments, both of which are wrong.

[smkhalsa]

Thank you for the PR!

One question: is there an advantage to using a possibleTypeOf Map instead of a possibleTypes Map? Apollo uses the latter, and it feels more intuitive to define possible types for an interface rather than possible interfaces for a type.

[smkhalsa]

We should include the possible types as an argument to operationRootData and pass them in here.

[budde377]

One question: is there an advantage to using a possibleTypeOf Map instead of a possibleTypes Map? Apollo uses the latter, and it feels more intuitive to define possible types for an interface rather than possible interfaces for a type.

I don't see any immediate benefits one way or another. Apollo using the latter is a good argument for going in that direction. I'll rewrite!

[smkhalsa]

LGTM