add isValueExpectedForType to handle abstract types

[lopert]

The fixture input validator doesn't currently handle GraphQL abstract types where different items can be different concrete types.

In this PR, when a field is missing from a fixture, we use typeInfo.getParentType() to determine the concrete type, and validate whether that field is actually expected based on the fixture value's __typename.

[adampetro]

This only works if the __typename selection isn't aliased, right?

[lopert]

Yup. Did not realize people would actually do this but it is possible. 😢

[adampetro]

concrete type if inside inline fragment

This is not necessarily true. You can have inline fragments whose type condition is an abstract type. Example:

interface MyInterface {
  myInterfaceField: String
}

type A implements MyInterface {
  a: String
  myInterfaceField: String
}

type B implements MyInterface {
  b: String
  myInterfaceField: String
}

type C {
  c: String
}

union ABC = A | B | C

type Query {
  abc: ABC
}

{
  abc {
    ...on MyInterface {
      myInterfaceField
    }
  }
}

[lopert]

Added a type to the schema to test this and updated the code to handle this by matching the schema's possibleTypes to the __typename value.

[adampetro]

Counterexample:

interface MyInterface {
  myField: String
}

type A implements MyInterface {
  myField: String
}

type Query {
  myInterface: MyInterface
}

{
  myInterface {
    ...on myInterface {
      myField
    }
  }
}

In this case empty objects should not be allowed

[lopert]

I've updated the schema and added a test case for this.

[adampetro]

Not sure how I feel about this concept. Because you can have theoretically many nested fragments, I think it makes sense to keep track of the set of possible types as we descend the fragments, and compare that to the set of possible types of the parent type. If the sets are not equal then we can accept an empty object. If they are equal, we cannot and need to validate further.

[lopert]

I've added logic in the latest commit to compare between the two sets.

[adampetro]

I was trying to say that the "grandparent type" alone isn't fully correct. There could be a number of types that we need to filter through. e.g.

{
  myField {
    ...on Interface1 {
      ...on Interface2 {
        ...on Interface3 {
          myOtherField
        }
      }
    }
  }
}

In this case, we need to see how many possible types there are in the intersection of whatever type myField is as well as Interface1, Interface2, and Interface3.

[adampetro]

If we changed it to node.typeCondition !== null && node.typeCondition !== undefined would it allow us to remove the !?

[adampetro]

Do we need this? I'm guessing we were using parentType before but now we're not?

[adampetro]

Inheriting from the parent is only correct if the selection is part of an inline fragment, not part of a field. Is there a way we can differentiate? Maybe split this out to entering inline fragments and fields? Or I think all of the arguments to enter are actually node, key, parent, path, ancestors, so we could include those in the signature to get access to the parent to check what it is.

[adampetro]

Nit: this doesn't implement an interface, feels weird to call it an interface implementer

[adampetro]

Are these useful? Should we just bail when we see the first error?

[adampetro]

There are a bunch of new tests with valid outputs, but should we have more with errors to know that we're properly validating and not accidentally skipping validating objects?

[adampetro]

(oops, accidentally hit approve when I meant to comment)