Skip to content
This repository has been archived by the owner on Sep 27, 2023. It is now read-only.

types nested under interface always marked as optional #66

Closed
mattkrick opened this issue Aug 31, 2018 · 2 comments
Closed

types nested under interface always marked as optional #66

mattkrick opened this issue Aug 31, 2018 · 2 comments

Comments

@mattkrick
Copy link
Contributor

OK bear with me on this one: All Animals make noise. A Dog is an Animal. A Bark is the kind of Noise a Dog makes.

IDL:

interface Animal {
  id: ID
  noise: Noise!
}
interface Noise {
  name: String!
}
type Dog implements Animal {
  id: ID
  noise: Bark!
}
type Bark implements Noise {
  name: String!
}

fragment:

animal {
  ... on Dog {
    noise {
    ... on Bark {
        name
      }
    }
  }
}

artifact:

readonly animal: ({
  readonly noise?: {
    readonly name: string;
  };
})

I believe it's a bug that noise is marked as optional here. Noise is guaranteed for all Animals, and therefore all Dogs (graphql forces all sub-type to be sub-classed & to have matching nullability).

This seems very close to #64, but it's a little nuanced since it only crops up when 2 interfaces are used.
Reproduction branch is here: https://github.com/mattkrick/relay-compiler-language-typescript/tree/double-int-null/example

@kastermester
Copy link
Contributor

This is because you don't request noise on something of type Animal but only on a Dog. If you remove the ... on Dog part this should work as intended.

animal {
  noise {
  ... on Bark {
      name
    }
  }
}

@mattkrick
Copy link
Contributor Author

you're exactly right! i was thinking that as long as every non-abstract type of animal was accounted for & requested noise that it would be guaranteed, which still holds true! But I guess that tightly couples the nullability to the resolveType of animal, which would put it in the same annoying boat as enums that aren't future proof.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants