Consider generating a sealed interface with an Unknown case for Union types in response-based codegen

[StylianosGakis]

Use case

Given a Union like:

union SomeUnion = FirstCase|SecondCase|ThirdCase
And a type:
type TypeContent {
  content: SomeUnion!
}

And in my query I got:

fragment "" on "" {
 content {
  ...ContentFragment
 }
}

fragment ContentFragment on SomeUnion {
  ...FirstFragment
  ...SecondFragment
  ...ThirdFragment
}

Then in my code at some point I am doing:

fun ContentFragment.toFoo(): Foo {
 when(this) {
  is FirstFragment -> ...
  is SecondFragment -> ...
  is ThirdFragment -> ...
  else -> 
 }
}

Describe the solution you'd like

That else in the last function means that if a new Union type is added to my schema my code won't catch the fact that I am not handling the new case, since it is "covered" by the else ->
Improving this to be part of a sealed hierarchy would be a great way to prevent accidentally making such a mistake

[martinbonnin]

Sorry for the delay, I just dug into that again and as always, there's more than meets the eye.

By default fragments are shared between modules, meaning you can do something like this:

module1/graphql/fragment.graphql
module2/graphql/operation.graphql # <- uses fragment.graphql

For this reason, we can't unconditionally generate everything as sealed. There are several choices:

1. Keep as-is
2. Detect whether the module containing the fragment is used by another module. That would work but this breaks the "isolation" of modules. Modules now need to know who uses them.
3. Disable sharing fragments between modules.
4. Big user-configurable flag that overrides everythying and always generates as sealed no matter what. If there is a misconfiguration, then the resulting Kotlin code doesn't compile anymore.

That last option might be useful but it's yet another setting in the huge list of settings...

[StylianosGakis]

Ah, of course there is more to it 😅

Please do help me understand, how does the fact that a fragment defined in one module can be used from another prevent it to be generated as sealed? This must just be something basic I do not know about here. The fragment itself is not going to be modified by the caller module, so the hierarchy that it represents should still be

  ...FirstFragment
  ...SecondFragment
  ...ThirdFragment

And then an else which is none of the three options.
If it's used by many different modules which part breaks here? Is it that you'd want to keep the interface open for those modules for some reason? Are those modules expected to be able to take this fragment and "expand" on it, while still having it be named with the same name?

[martinbonnin]

Say you have this:

# module1/graphql/fragment.graphql
fragment queryDetails on Query {
  __typename
}

# module1/graphql/GetQuery1.graphql
query GetQuery1 {
  ...queryDetails
}

The pseudo generated code looks like so:

// let's assume we can make the fragment sealed for now
sealed interface QueryDetails {
  __typename: String
}

data class GetQuery1 {
  // note how the data class implements `QueryDetails`
  data class Data: module1.QueryDetails { 
     override val __typename: String
  }
}

Now let's add a new module, module2, that is going to use that same GraphQL fragment:

# module2/graphql/GetQuery2.graphql
query GetQuery2 {
  ...queryDetails
}

Generated code is like so:

data class GetQuery2 {
  // we want to implement `QueryDetails` but we can't because that hiearchy is sealed in module1.
  // it's too late now.
  data class Data: module1.QueryDetails { 
     override val __typename: String
  }
}