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?

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

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.

Ah, TIL Arrow has something for this!

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

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

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?

Yea correct if

null

is a valid response then

@nonnull

will make the whole request fail

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 😂

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

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.

makes perfectly sense!

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