https://kotlinlang.org logo
a

Andrew Kelly

12/06/2019, 12:27 PM
@Clara Bayarri I saw your talk at KotlinConf on Compose, and specifically about the Single Child Composable Problem you mentioned. Is it not possible for something like a Button to query the number of children in the lamba and throw a warning if its more than 1? That’d force me as a developer to then include a Row or Column to wrap multiple children, the Row/Column children lambdas would be unbounded in the number they could include.
m

mzgreen

12/06/2019, 12:47 PM
I wouldn’t be surprised if those multiple views are drawn on top of each other if no row/column is explicitly added (just like framelayout does it). But maybe I’m thinking too much in terms of current UI framework.
a

Andrew Kelly

12/06/2019, 1:12 PM
In the talk they mentioned possibly having a sensible default, like wrapping them in a Row automatically.
l

Louis Pullen-Freilich [G]

12/06/2019, 2:09 PM
There's no way to query the number of children in the lambda (currently, anyway) - it's just some arbitrary code that will be executed during composition - it may result in 0, 1, or many children. It's theoretically possible to do static analysis at compile time and throw a compilation error, but that's very tricky to do and would require a lot of work in the compiler layer
a

Adam Powell

12/06/2019, 3:03 PM
More than that though, it complicates the type system in ways that can't be hidden from developers who haven't reached a certain level of sophistication yet. It implies a form of inferencing that would make implementation detail changes deep in other composable functions binary incompatible, and/or the need to forward-declare child count everywhere using something akin to contracts.
a

Andrew Kelly

12/06/2019, 10:59 PM
Then perhaps as @mzgreen suggests the Composables should just stack like a FrameLayout if we declare more than 1 for something like a Button. Then as a developer when I Preview the composable it’d render all strange and I’d be like “oh yeah, I need to define a Row/Column/ConstraintLayout to have them laid out properly”. Sensible defaults are fun until they’re different, e.g. if the sensible default for Button is to wrap the children in a Row, but the sensible default for Card is to wrap the children in a Column, then things might get confusing to the uninitiated as to why things magically work, but in different ways.
m

mzgreen

12/07/2019, 10:28 AM
Yes that's exactly what I was trying to say, thanks :)
a

Adam Powell

12/07/2019, 2:21 PM
Yeah, that's where we were at for a while too. 🙂 It started getting less and less defensible in practice, especially with some composables that really blur the line between being this kind of slot content or a layout itself. The fuzzier the line got, the less sensible that became as a default
At some point it becomes a judgment call
5 Views