In a query I got, I got a field which is nullable,...

# apollo-kotlin

[Stylianos Gakis]

In a query I got, I got a field which is nullable, say newestMessage: ChatMessage.
In the business logic for this specific case all I care for is if it's null or not, not really interested in its internal state.
Right now in the .graphql file I specify:

newestMessage {
  id
}

Or even

newestMessage {
  __typename
}

but IDE plugin is hinting to me that I am not using it and it's greyed out.
I can't do newestMessage {} either as that's an error.

I suppose there's no better way around this other than slapping a # noinspection ApolloUnusedField on top of the id field right?

[wasyl]

Should __typename ever be unused? 🤔 I think it's always fetched anyway

[Stylianos Gakis]

Yeah I suppose the IDE plugin is looking at user-code, so it makes sense that it marks it as unused. But perhaps it should make an exception for this?

Btw the id in this case is in fact the primary key too, aka in my extra.graphqls I got extend interface ChatMessage @typePolicy(keyFields: "id"), so from previous discussions here I understand that I will also fetch that one regardless of if I specify it or not. So both of them I suppose "technically" are never not asked for? Perhaps?
Doing some guess-work here, that's why I came here to ask in the first place 😄

[mbonnin]

I think it’s always fetched anyway

It’s always fetched and might end up being used by the normalized code but this is “unsafe” access, i.e. it’s accessed at the JSON level, before it’s turned into typesafe Kotlin so the IDE doesn’t know about those usages

[mbonnin]

always

Actually, it “depends”, there’s a parameter for that

[Stylianos Gakis]

> Actually, it “depends”, there’s a parameter for that
Is this for __typename or for the ˚keyField"?

[mbonnin]

For __typename (it’s called addTypename (kdoc))

[bod]

Should __typename ever be unused? 🤔 I think it's always fetched anyway

It's automatically added to your queries - but if you explicitly query it, then I think it makes sense to check if you actually use it in your code?

[Stylianos Gakis]

I think it makes sense to check if you actually use it in your code

Yeah that's what I assumed here too. So perhaps the "# noinspection ApolloUnusedField" is the most reasonable approach for my use case?

[bod]

I think so yes 👍

[mbonnin]

I’m not sure why GraphQL forbids empty selection sets, that would solve this issue

[Stylianos Gakis]

A bit unrelated perhaps, but regarding:

For __typename (it’s called addTypename (kdoc))

I see two interesting things here:
• "ifFragments" (deprecated)
• Default value: "ifFragments"
The default is the deprecated one? And afaik there's no reference to this in the 3.x->4.x migration guide.
is this something that we should optimally not leave as the deprecated option? I've never seen it before so I've never given it any thought before.

[mbonnin]

I’m a bit anxious at changing this default but don’t want people to explicitely use “ifFragments” either, hence the current situation

[mbonnin]

There are 2 situations:
• normalized cache users want "always" because if an interface is introduced, a missing __typename might introduce a cache miss
• other users want "ifPolymorphic" because __typename wastes bandwidth and looks not cool in the JSON

[Stylianos Gakis]

Who wants ifAbstract? 😄

[mbonnin]

Probably me cause it’s easy to implement 😄

[mbonnin]

But could probably be deprecated

[Stylianos Gakis]

So for current normalized-cache users who are just using the default "ifFragments", it's the default behavior, but it's technically introducing some cache misses that could be avoided with "always" right?
And is the "always" that much heavier for it to not be a safe bet to use as a default?
Or are you worried that people will experience behavior change (even if it means "more correct" cache hits) that people may rely on?

[mbonnin]

it’s technically introducing some cache misses that could be avoided with “always” right?

exactly, it’s suboptimal

Or are you worried that people will experience behavior change

That. Changing that is a pain because it changes a lot of models. Typical use case is users creating their data classes manually in unit tests.

[mbonnin]

Changing to always will require everyone to pass a __typename argument to every model, this is not fun. Especially for users that are not super familiar with GraphQL , it feels very weird. Where does this __typename come from? 🤷

[mbonnin]

And is the “always” that much heavier for it to not be a safe bet to use as a default?

That’s also a concern actually. I’m not 100% about the “heaviness” of it. With gzip it should compress quite well but it’s still surprising to a non-negligeable portion of users and creates friction. See https://github.com/apollographql/apollo-kotlin/issues/1018 for an example