Hello! Quick question about the `@optional` direct...

# apollo-kotlin

[Eduard Boloș]

Hello! Quick question about the @optional directive when used on a non-nullable object. In the generated model, the respective field becomes nullable, but in the *Selections object, the annotated field's type is still marked with .notNull(), making it a CompiledNotNullType. Is that on purpose?
Context: we do some shenanigans in our CacheResolver to avoid some cache misses by returning null instead of nullable fields, and we were trying to do this for a field that is marked not null in the schema generated from the backend, so that we can successfully execute the query even if the user is offline (e.g. with NetworkFirst).

[bod]

Interesting! I'm guessing this is not on purpose.

Would partial results from the cache help you there?

[Eduard Boloș]

That's what we are basically trying to achieve, get the data which is in the cache, and null out the missing part. Is there a better mechanism to achieve this? 😄

[bod]

Not easily in the current version, but we recently added this feature in the new cache. Although it may not be ready for production yet, it would be great for you to have a look and see if that would help with your use-case.

[bod]

however - you would still have the same issue for non-nullable fields 🙂

[bod]

Maybe you will have more luck patching your schema to make the field in question nullable, rather than using @optional.

[Eduard Boloș]

Ah, that's what you were referring to 🙂 I had a previous look at it when investigating a way to set a max age to cache entries, see this thread. I see that meanwhile you added an example on how to migrate the data from the old format to the new one, that's cool! 🙂 But yeah, not sure that we want to use it in production already 🙃 Otherwise, it looks promising.

Maybe you will have more luck patching your schema to make the field in question nullable, rather than using @optional.

Yeah, ultimately this is what we are going to do, but it has a slightly longer turnaround, and semantically the field will never be null from the server, we just make it nullable to hack our own partial response mechanism 😄

[Eduard Boloș]

But getting back to my initial point, would making the selection field also non-notNull be something that should happen when using the @optional directive? (aka, should I open a bug ticket on GH? 😄)

[bod]

would making the selection field also non-notNull be something that should happen

I think it's debatable because the type itself is still non nullable in the schema - it's the selection field that is marked (and generated) non null.

But maybe it would still make sense - so an issue would be welcome 🙂

[bod]

In the meantime I think an Apollo compiler plugin could also help you - since it can transform the IrOperations (where the nullability of fields is stored)

[bod]

Also just thinking out loud - instead of null wouldn't it make more sense to have an actual value? That would avoid this whole problem 🙂 (But I guess this would be less easy to build something generic)

[Eduard Boloș]

Yeah, being able to specify some default value instead of null would be amazing 😄 It would help differentiate between a legit null value from the backend vs a fallback null xD But it's not the end of the world, for now at least.

A compiler plugin-based solution would be cool, but it's a lot more work than our current CacheResolver-based one 😅

I will open an issue on Monday, cheers!

[Eduard Boloș]

Done here.