Generate a Kotlin enum without the UNKNOWN__ case

[joshuakcockrell]

Use case

Currently, when statements need to match .UNKNOWN__ every time they're used in a codebase.

when(color) {
  BLUEBERRY -> TODO()
  CANDY -> TODO()
  __UNKNOWN -> TODO()
} 

This means I need to think through the UNKNOWN fallback several times.

If the Apollo codegen provided an enum that didn't contain this case, I could instead write

when(color.unwrap()) {
  BLUEBERRY -> TODO()
  CANDY -> TODO()
} 

Yes, nothing's currently stopping me from writing an unwrap() extension, but I still need to sprinkle __UNKNOWN throughout my codebase to get the when statements to compile.

This is how Apollo iOS works, btw. GraphQLEnum.unknown is instead a wrapper enum around the core enum. On first glance, you would think Kotlin's approach is nicer because you don't need to match .case(...), but every single when statement needs a default case to handle the .UNKNOWN__, whereas iOS I can just create an unwrapper at the top level of my project to handle .unknown once.

Describe the solution you'd like

Apollo Kotlin already generates knownEntries List. If it just provided this exact thing in enum format I could write my own project level unwrap() and my individual when statements would never need to worry about .UNKNOWN__.

More context

Discord thread

[joshuakcockrell]

For the record, after using both iOS & Kotlin Apollo libraries, I do like Apollo Kotlin's enum approach better as a starting point. Seeing Getting Started examples that have .case(..) is kinda gross on iOS. But I'd say Apollo iOS wins for the power use cases once you figure out how to write your own .unwrap() extensions.

Ideally, Apollo Kotlin could just codegen a knownEntries enum and that's the best of both worlds.

[martinbonnin]

@joshuakcockrell an implementation is available at #6248. Let us know what you think

[github-actions]

Do you have any feedback for the maintainers? Please tell us by taking a one-minute survey. Your responses will help us understand Apollo Kotlin usage and allow us to serve you better.

[joshuakcockrell]

Wow, that's a crazy fast turnaround on this! I'm excited to test this out. Will let you know how it goes.

[martinbonnin]

Damn, I didn't mean to close this issue so fast, forgot that merging the PR would close the issue 🤦
In all cases, let us know how it goes, it's available in the SNAPSHOTs now.

[martinbonnin]

@joshuakcockrell did you get a chance to test this? Just want to make sure it's working for you while while it's still hot.

[joshuakcockrell]

@martinbonnin I've been having difficulty getting the snapshot working. I got 4.1.1-SNAPSHOT working but couldn't see any difference in the generated code. I'll try again today.

[martinbonnin]

Hi @joshuakcockrell any update here? Would be nice to get confirmation it fits your use case before we cut a release.