Proposal: Support union scalar types

[stubailo]

It makes sense often to have a field that could return, for example, an Int or a String. It would be convenient to be able to use a resolveType-like mechanism to determine how the value is serialized. This would be even more useful for custom scalars.

The specification currently says: "GraphQL Unions represent an object that could be one of a list of GraphQL Object types", which basically means that unions are the same as interfaces, but without any shared fields. Supporting unions of scalars would further differentiate unions from interfaces.

[rmosolgo]

Could you share a couple of concrete use cases? I ask because, personally, I'm usually reading values right out of MySQL (or running those values through transformations with predictably-typed output), so I haven't needed this yet!

[migueloller]

@rmosolgo,

Here is a concrete use case that we've come across at my team. I have a couple more if you need them.

We've got an algorithm that produces results based on location. We have an enum AreaOfTown that contains all possible areas of town to filter the results. Here's the catch, the algorithm can also filter locations by "near me". Because we can't simply make a union that is AreaOfTown | "NEAR_ME" for the input type, then we have to create a completely new enum that contains all of the values in AreaOfTown and "NEAR_ME". This is undesirable because if we ever change the AreaOfTown enum by adding more (this will 100% happen in the future), then we have to make sure we also update our other enum.

If we could write scalar unions then it would solve this problem for us, among others (we would like to have constructs like Int | [Int!] or Int | String like @stubailo mentioned).

[stubailo]

In our case, it's because we were returning a structure that represented a JSON tree, where keys can be integers (in the case of arrays) or strings (in the case of objects). We ended up compromising for now to just use strings, but I can imagine how this would be extra useful in the case where you want to return one of a set of custom scalars, which might have different serialization logic.

[migueloller]

Here are other relevant discussions:

• GraphQLUnionType as input type graphql-js#207
• Union of Non-Object Types graphql-js#291
• Union input types #202

@leebyron made some good points in his comments here.

[marcintustin]

Allowing uniontypes to contain primitives allows us to model any kind of source that can be polymorphic in its source data. For example, avro data or elasticsearch.

This is a severe limitation on exposing existing data, rather than creating new systems that are defined by graphql from the ground up.

[leebyron]

What's still unclear to me is what a valid query would look like which encounters such a union, and how should well-typed clients determine what to expect from such a query?

Consider:

type MyType {
  field: String
}

union MyUnion = String | MyType

type Query {
  example: MyUnion
}

[marcintustin]

Like with any union - it has to be prepared for any item in the union. I don't see that this poses any special problems.

…

On Wed, Feb 8, 2017 at 7:52 PM Lee Byron ***@***.***> wrote: What's still unclear to me is what a valid query would look like which encounters such a union, and how should well-typed clients determine what to expect from such a query? Consider: type MyType { field: String } union MyUnion = String | MyType type Query { example: MyUnion } — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#215 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABLqONw9c-XUFzYcBYSTtPU2GGBsr5J7ks5ramNMgaJpZM4KLagd> .

[leebyron]

For the above schema consider the query:

{ example }

It's clear what this query should return if the example field returns a String at runtime, but what should it return if the value was a MyType?

Similarly:

{ 
  example {
    ... on MyType {
      field
    }
  }
}

It's clear what this would return for MyType, but what should it return for a String?

[marcintustin]

The exact same thing as querying a value that doesn't exist on a member of a union.

…

On Wed, Feb 8, 2017 at 8:36 PM Lee Byron ***@***.***> wrote: For the above schema consider the query: { example } It's clear what this query should return if the example field returns a String at runtime, but what should it return if the value was a MyType? Similarly: { example { ... on MyType { field } } } It's clear what this would return for MyType, but what should it return for a String? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#215 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABLqONSR3whAYxVVrPBjdCmGOT_Py57tks5ram2rgaJpZM4KLagd> .

[leebyron]

It's not clear to me what that means. What would a valid query look like that would clearly give a value for a primitive type or an object type?

[leebyron]

Specifically http://facebook.github.io/graphql/#sec-Leaf-Field-Selections is what I'm referring to as "valid query"

[stubailo]

I think the original issue is about having unions where every member is a scalar right? Not unions between scalers and objects?

[OlegIlyenko]

just an idea. Maybe it would make sense to introduce special inline fragment semantics for scalars:

{ 
  example {
    ... on String {
      value
    }
    ... on MyType {
      field
    }
  }
}

This can be generalized by allowing scalars to be used as leafs (current semantics) and as objects with a single field (value). A huge advantage of this approach is that one can use __typename introspection on scalars.

In our API we have a similar issue. For some parts of the schema, we even have introduced object types like StringAttribute, IntAttribute, etc. in order to unify object attributes ("attributes" are a part of user-defined data structures which our service supports) and scalar attributes and provide same introspection capabilities for both.