Maybe a bit of arch or code style.... but what do ...

# compose

[juliocbcotta]

Maybe a bit of arch or code style.... but what do you folks think of composables that accept nullalble values that short circuit the composition like

@Composable
fun Label(val label: String?) {
   if(label == null) return
   ...
}

or even

@Composable
fun Label(val label: String?) {
  if(label != null){
    ...
  }
}

to me it looks like a bad practice and the nullability check should be at the calling place as receiving that null value will in fact not draw anything... WDYT folks?

[rkechols]

I don't think it's an issue to have the parameters nullable. It can potentially save you a lot of null-checks elsewhere, consolidating the checks to one place.

[juliocbcotta]

I can see that, but at the same time we can have multiple composable calls that do nothing, I don't know how much more expensive it is though...

[rkechols]

Ah, I was not thinking about runtime efficiency, but was just focusing on "code style".

I don't know how expensive it is to have the null check inside vs outside the composable, but even small things can add up when repeated often. I don't think having the null checks inside would cause visible lag in the application, but having the null checks outside would certainly mean it's more efficient by at least a small amount.

[Blundell]

if the null check is inside, the param is optional, if it is outside the param is required.

The optionality of a param should/could be down to the composable itself. "Sure i can handle having no label". The implementation may be a quick return null check, or it could be a default label. If you have that check outside of the composable then the optionality is no longer the composables responsibility and two clients could do different things for the optional value.

Both these are valid design choices

[Zach Klippenstein (he/him) [MOD]]

If you really want the syntax but don’t want to potentially waste a composable call (unlikely to have any affect on performance unless the call is super hot): you could make your main composable take non-null, and create an overload that is inline that takes a nullable param and does the null check. But I would probably consider this over-engineered.