Allow Interfaces in Unions

[jansenignacio]

Is it possible to allow Interfaces to be one of the types of a Union? I'm also interested to know why this is not allowed.

[dschafer]

Is it possible to allow Interfaces to be one of the types of a Union?

It's not permitted in the spec, no: http://facebook.github.io/graphql/#sec-Union-type-validation

I'm also interested to know why this is not allowed.

So we actually tried this within Facebook's implementation for a while, and we found the complexity wasn't worth the benefits. Let's make it concrete; say we had:

type A {
  color: String
}

type B implements Named {
  name: String
}

type C implements Named {
  name: String
}

interface Named {
  name: String
}

union SomeUnion = A | Named

On the client, when it sees a field of type SomeUnion, it will almost certainly have to ask for __typename to see what type it got; in doing so, it will either get A or B or C back. In particular, it's not clear what we gained here compared to just having

union SomeUnion = A | B | C

which is more explicit.

One potential benefit is that on the server, if someone added a new type D that implemented Named, we would be able to return it from SomeUnion with no additional changes. It's not immediately clear if that's a desirable behavior, but even if it is, that could be easily implemented as a helper method on the server that inlined all of the implementations of Named into SomeUnion, without needing to tell the client about that.

The other potential benefit is that if the client knew that any Named was possible to be returned from SomeUnion and it saw a type it didn't recognize, it could try and duck type it against Named to potentially handle it. This is pretty reasonable... but in practice we never saw that happen, and instead every client would just "expand" the union from A | Named to A | B | C and handle it as though it was the latter.

So while it would have been reasonable to allow Union to include Interface (or even potentially other Unions), it added complexity and didn't seem to add much (if any) benefit, so we decided to simplify things and have them only return Object.

There might have been other reasons as well which @leebyron might know, but the above is how I've thought about it.

[axos88]

@dschafer: Just ran into this, thanks for the explanation! 👍

[kamilchm]

I got a little more complicated case. I need to describe a UI structure where I have two types of elements - Components and Containers. My full schema is about 300 lines long, so I'll try to show a little simplified version:

interface Component {
  color: String!
}

type Button implements Component {
  color: String!
  text: String!
}

type Label implements Component {
  color: String!
  text: String!
}

type Badge implements Component {
  color: String!
  text: String!
}

type Carousel implements Component {
  color: String!
  images: [Image!]!
}

type Divider implements Component {
  color: String!
  space: Int!
}

type Image implements Component {
  color: String!
  imageUrl: String!
}

type Video implements Component {
  color: String!
  videoUrl: String!
}

interface Container {
  children: [UIElement!]!
}

union UIElement = Component | Container # FIXME: what to put here?

type LinearContainer implements Container {
   children: [UIElement!]!
  direction: String!
}

type FlexContainer implements Container {
  children: [UIElement!]!
  justify: String!
}

type Query {
  screen: [UIElement!]!
}

It looks natural to have a union of interfaces here. Otherwise, it means an error-prone repetition:

union UIElement = LinearContainer | FlexContainer | Button | Label | Badge | Carousel | Divider | Image | Video

I need to remember to put a new type here, every time I add new Component or Container and
it's not clear if it's intended to have it all, or this was meant to include only some of Components and Containers. How to describe such a dependency when the type system lacks constructs to do this?
@dschafer how would you dealt with this?

[mjmahone]

1. It's unclear why the repetition is error-prone. Unless you're hand-writing your schema, and if you are you could still write custom validation method to ensure all Component or Container types are in your UIElement union.

2. I wouldn't use a Union for this at all: I'd use 3 interfaces.

interface UIElement {
  dom_id: ID # some shared field across both interfaces
}
interface Container {
  dom_id: ID 
  children: [UIElement!]!
}
interface Component {
  dom_id: ID
  color: String!
}
type FlexContainer implements Container & UIElement { ... }
...

and with interfaces being able to implement other interfaces in V15, you'll automatically get the validation rule I talked about above if you did:

interface Container implements UIElement { ... }
interface Component implements UIElement { ... }

[stephenhandley]

Things get pretty unwieldy when querying on a union in the client that involves an interface with many implementing types... the repetition blows up.

interface Foo { 
  id: ID!
  name: String!
  ...
} 

interface Bar {
  id: ID!
  title: String!
}

type FooA implement Foo {...}
type FooB implements Foo {...}
type FooC implements Foo {...}
...
type BarA implements Bar {...}
type BarB implements Bar {...}
...

enum CommentableType {
  FooA
  FooB
  FooC 
  ...
  BarA
  BarB
  ...
}

type Comment {
  id: ID!
  text: String!
  author_id: ID!
  commentable_type: CommentableType!
  commentable_id: ID!
  commentable: Commentable!
}

type User {
  id: ID!
  email: Email! 
  comment_ids: [ID!]!
  comments: [Comment!]! 
}

union Commentable = FooA | FooB | FooC | ... | BarA | BarB | ... // imagine when this is 30+ types 

And as a dumb example, let's say you were trying to query a user's comments

viewer {
   id 
   email
   comments {
     id
     text
     commentable {
        ... on FooA {
           id
           name
       }
        ... on FooB {
           id
           name
       }
        ... on FooC {
           id
           name
       }
       // more Foo*
        ... on BarA {
           id
           title
           ping
       }
        ... on BarB {
           id
           title
           pong
       }
       // more Bar*
    }
}

When you have lots of implementing types it would definitely be preferable to do this for the union, especially if the base interface for Foo and Bar had more than just two fields.

union = Foo | Bar

and the following simpler query

viewer {
   id 
   email
   comments {
     id
     text
     commentable {
        ... on Foo {
           id
           name
        }
        ... on Bar {
           id
           title
       }
       ... on BarA {
          ping
       }
       ... on BarB {
          pong
       }
    }
}

[benjie]

Unless I’m misunderstanding, you can already do that for the query: you can spread over an interface type within a union type so long as at least one type within that union implements that interface. I.e. the last query is already valid.

So, if I understand, you’re just asking for a more convenient syntax for defining your union as containing all the interface types, which seems like a job for schema build tooling.