I’ve seen the ideas of doing client-side @nonnull,...

# apollo-kotlin

[Stylianos Gakis]

I’ve seen the ideas of doing client-side @nonnull, but is there a notion of doing @nullable?
There’s basically a query I am doing, which has a bunch of fields, and one of those fields is non-null. However this has happened to be null sometimes, due to some backend service experiencing some issues or something like that, which then breaks the entire query. In this particular case, it’d actually be totally fine client-side to not get this data and just render the rest.
Is there something I am missing that I can do aside from editing the schema file to remove that ! from that specific query response type?

[mbonnin]

There's something like that in client controlled nullability. It's called error-boundaries

[mbonnin]

It's not in Apollo Kotlin yet but that one goal for v4

[Stylianos Gakis]

Interesting, yeah that’s gonna be nice to be there for 4.x. For now do you find any issue with simply editing the schema itself as I download it to remove the !?

[mbonnin]

Yup, that should work

[mbonnin]

Of course it's better if your server does it

[Stylianos Gakis]

Yeah definitely, since if they don’t the other clients will also be getting broken data. I mostly wanna do this now for my dev environment so that I don’t need to change too much code to continue testing something else, and will try to address this in the real schema. Thanks for the help! 🤗

[Stylianos Gakis]

Bumping this, now that we're in rc01 for v4, was there any progress on this perhaps?

[mbonnin]

Lot of things happening in the nullability space 🙂

[Stylianos Gakis]

Now that I searched a bit more, I do see this directive @optional(if: Boolean = true) on FIELD | VARIABLE_DEFINITION in here https://specs.apollo.dev/kotlin_labs/v0.3/#@optional 👀

[mbonnin]

CCN has been more or less abandoned though because your initial problem requires a backend fix

[mbonnin]

There’s a dedicated page in v4: https://www.apollographql.com/docs/kotlin/v4/advanced/nullability

[Stylianos Gakis]

Ah alright. Yeah this was yet another such case actually. Backend had a bug, so it returned null on some odd scenarios, and I wanted to see if I can do a client-side fix temporarily 😄 Just like back then, 1 year ago.

And yeah that directive is about generating them as optionals, nothing to do with what I was looking for here

Thanks for the link, gonna look through it now

[mbonnin]

There is a loooooooot of discussion but to your initial question, I think removing the ! manually is still the way to go

[Stylianos Gakis]

If a non-null field is annotated with this new @catch(to: NULL), it would still not be turned into null, since the error is not on the "errors" list, but it's a nullability problem I assume?

[mbonnin]

If a non-null field is annotated with this new @catch(to: NULL),

In the current implementation, adding @catch to a non-null field isn’t helping because the field itself isn’t wrapped in an ErrorAwareAdapter (because it’s never supposed to be an error)

[mbonnin]

It’s more for the other way around

[mbonnin]

Wait, this is why you had to rewrite your schema, right? (that other thread about ApolloDownloadSchemaTask 😄 )

[mbonnin]

I think this is the “good” fix there. The server is lying but the client knows better and “overrides” that locally.

[mbonnin]

The schema being the contract, rewriting the schema seems ok to me

[Stylianos Gakis]

Wait, this is why you had to rewrite your schema, right? (that other thread about ApolloDownloadSchemaTask

Actually my original reason is that I wanted the schema to not have double line breaks https://github.com/HedvigInsurance/android/blob/82da9c63ae3523f8d06bda1fa595628ef6[…]uild-logic/convention/src/main/kotlin/ApolloConventionPlugin.kt purely for reasons of readability, and I do not regret it a single bit that I am pulling off accessing internal things shenanigans just for this 😂

This mistake on the backend is just a temporary thing which will be fixed anyway but I wanted to make it easier on me for now, that's all 😄

[Stylianos Gakis]

And with all that said this makes sense to me now yeah, and why the catch directive wouldn't fit what I am saying here.
The docs linked are great, thanks for linking (and writing of course 😅)!