I had recently updated to 3.0.0-beta01, and today ...

# apollo-kotlin

[Neal Sanche]

I had recently updated to 3.0.0-beta01, and today updated my dependencies to 3.0.0-beta02 and nothing compiles anymore. I must be missing something. I get a lot of things like: ApolloRequest<GetUserQuery.Data> but Query<TypeVariable(D)> was expected and Unresolved reference: hasErrors and a bunch more like this. I'll keep looking.

[mbonnin]

You've hit the fluent API changes:

val request = ApolloRequest.Builder(HeroQuery()).fetchPolicy(FetchPolicy.NetworkOnly).build()
val response = apolloClient.query(request)

becomes

val response = apolloClient.query(HeroQuery())
        .fetchPolicy(FetchPolicy.NetworkOnly)
        .execute()

[Neal Sanche]

IDE caching issues. Cleared cache, and now I see there is an execute() method available that wasn't there before.

[Neal Sanche]

Today I'm trying to get some changes through to our iOS guy. He hates the sealed classes because they come out in a very 'un-swift' way. And for some reason we are getting classes with underscores in them. Hoping that beta02 does something different in some of these cases.

[mbonnin]

He hates the sealed classes because they come out in a very 'un-swift' way

I see... In that case, you can use

sealedClassesForEnumsMatching.set(emptyList())

to generate enums

[mbonnin]

This was intended to be removed but maybe we can keep it if it makes iOS cumbersome

[mbonnin]

And for some reason we are getting classes with underscores in them

Would you have an example?

[Neal Sanche]

He's biting this sealed classes bullet for the sake of making less future work for us.

[Neal Sanche]

Yeah, for the _ classes, this started happening in beta01. Not sure if it happens in beta02 yet, just updating. But the class was called Money. We have a data class called Money in a different package, and one of our GraphQL queries also has one. So, the GraphQL code generator, I think, decided to add an underscore.

[Neal Sanche]

Or maybe this is a KMM thing happening. Not sure yet.

[mbonnin]

The codegen adds very little _ . IIRC, this only happens for kotlin keywords like for , fun , object , etc..

[Neal Sanche]

Okay. I'll keep an eye out for that one. It's strange. Only seems to appear for the iOS target, so I'm suspecting Kotlin Multiplatform did it.

[mbonnin]

Let us know what you find!

[Neal Sanche]

One final thing, as I go through this migration, what happened to the queryCacheAndNetwork function?

[mbonnin]

It's executeCacheAndNetwork now

[Neal Sanche]

Okay. Cool, thanks. Nice easy one.

[mbonnin]

And it's on ApolloQueryCall

[mbonnin]

Will add that to the Changelog, sorry we missed it

[mbonnin]

Sorry for all the changes, these are the final API tweaks before we go stable

[Neal Sanche]

It makes more sense as part of the execution flow, I just didn't find it because it used to be on apolloClient.

[mbonnin]

I think it's for the greater good as the chaining of cals makes it easier to configure requests but if you have anything you find awkward, it's still time to say it !

[Neal Sanche]

The fluent APIs look nicer. 🙂

[bod]

Hi @Neal Sanche! Following your feedback (thanks!) we created this issue about the sealed classes generation. Please don't hesitate to comment on it (and share it to your iOS coworker 🙂) with any insights!

[bod]

a followup on this: we're trying to dig more on why sealed classes are not as nice to use as enums in Swift - in the issue we compared their usage and couldn't really conclude anything obvious - but obviously we're not Swift developers 😄 . If you have more info on this, it would be appreciated 🙂

[Neal Sanche]

Yes. Sealed classes end up looking like Blah.ENUM_VALUE() in Swift. Whereas the enums end up looking like Blah.enumValue which is closer to what Swift enums look like. The fact that sealed classes have to be instantiated seems really odd. We ended up going that route, even though they look strange.

[bod]

Thanks for the feedback! In my case, with the small example I played with (details are on the issue), it doesn't look like the sealed classes were renamed to all caps 🤔

[bod]

A follow-up on this: we decided to go back to make the generation of enums the default behavior (and keep the ability to generate sealed classes as an opt-in - just like it was on 2.x). This will be effective in the next beta. Sorry for the disturbance and thanks again for the feedback! 🙂