Was having a discussion about how to model a list ...

# apollo-kotlin

[Stylianos Gakis]

Was having a discussion about how to model a list which may be empty or not through GQL.
If the type is [x!], the backend can return:
• a null list
• an empty list
• a list with items in it.
In any way, on the clients you need to be defensive for both the null list case. And the empty list case
The type can be [x!]!. This way the backend can return
• an empty list
• a list with items with it.
What we would optimally wish for, is to be able to represent either:
• A null list
• A NonEmpty list
But there currently isn’t a way to represent this in GQL language right?
What we’re opting to go with, is [x!] and simply put the burden on the backend not to accidentally return a non-null list which is in fact empty. And just to be sure about it, also would need to be defensive about it in the clients in case the backend accidentally does so. That’s our best bet here I assume right?

[mbonnin]

I think you're 100% right, there's no way to represent a non-empty list in GraphQL. There's none in Kotlin either so in some ways this maintains symmetry

[mbonnin]

would need to be defensive about it in the clients in case the backend accidentally does so.

You have @nonnull to handle this automatically during parsing (doc, blog post)

[Stylianos Gakis]

Yeah, wish I could just use arrow’s NonEmptyList for this. I’m sure there is a way to somehow get something like that written, but probably not something I’d be able to figure out quickly 😄
I should maybe instead do this mapping myself in app-code instead.

[mbonnin]

Ah, TIL Arrow has something for this!

[Stylianos Gakis]

Yeap, in the core package. It’s pretty awesome, I’ve used it to model some stuff and honestly it’s so nice!

[mbonnin]

You can always use a custom scalar albeit there's no generics in GraphQL so you have to make a new one for each item type

[mbonnin]

There have been some discussions about GraphQL generics in the past (here). Not sure the current status

[Stylianos Gakis]

About @nonnull, as I understand that, I don’t want to use that there, since a null list is in fact a valid response from the backend no? Since if I say it’s nonnull, but it is in fact null, it’s just make the type “above” it null right?

[Stylianos Gakis]

You can always use a custom scalar albeit there’s no generics in GraphQL so you have to make a new one for each item type

Yeah definitely not worth the effort then imo for my use case

[mbonnin]

Yea correct if null is a valid response then @nonnull will make the whole request fail

[mbonnin]

So probably not what you want

[Stylianos Gakis]

Awesome, thanks a lot for the clarifications!
And let’s hope for someone to include some sort of NonEmptyList and generics in the GQL language spec in the next… let’s say 10 years 😂

[bod]

out of curiosity, why do you prefer a null list over an empty one?

[Stylianos Gakis]

The idea was that having the list be nullable, it kinda forces the clients not to “blindly” consume the list as it comes. Makes the client dev stop and think about how to handle the empty-list. Since if it’s null, Kotlin (and Swift) forces you to handle this case, you can’t go around it.
If it’s empty, you can make the mistake of not thinking of that case, and then rendering things that shouldn’t be there if the list is empty (think a header before a list is going to be rendered, or a divider after each item, a dropdown which will then contain 0 items and so on).

Now if you ask me personally, I am paranoid enough for these things that I’d check for the empty case too, but it’s just an effort to try and help the clients make less mistakes, that’s the entire idea, which I also very well understand.

[bod]

makes perfectly sense!

[Stylianos Gakis]

We need someone from the #arrow team to spread the word about NonEmptyLists is what I get from all this tbh 😂