https://kotlinlang.org
Join Slack
Question - one thing I struggle with when writing Flutter apps is when to use what containing widget...
# compose
a
Question - one thing I struggle with when writing Flutter apps is when to use what containing widget. There's stacks, rows, columns, containers, expanded widgets, center widgets etc etc. On the react native side, there's really only a view and then flex modifiers. It seems like compose is erring more towards the flutter style containment than the react/web style containment (though I'm aware of FlexColumn). I'd love to hear about what kind of discussion happened around that topic
a
Quite a bit of discussion happened around it 🙂
we started here initially because it's the model Android has always used; each parent is fully responsible for the measurement and layout of its children and that's at the parent's discretion
I haven't been happy with aspects of the Android measure/layout contract for years and wanted to address some shortcomings it had, and Flutter had addressed a few of them already so we integrated several of the insights they had around measurement constraint format and multipass restrictions
and in hindsight this model has paid off quite a bit for Android, most recently in the form of ConstraintLayout and MotionLayout. By leaving layout open for extension rather than prescribed from the outset, ConstraintLayout is able to exist
and the tooling experience around it
Romain and I spent years talking about how custom ViewGroup layouts are pretty easy to write when you have a specific use case and you know exactly what you want, and by and large it was true - you just also had to implement the rest of view concerns alongside it, which wasn't so fun
so for compose we set out to sort of make good on that promise, and I think we've gotten pretty close with the 
Layout
composable
and 
ConstraintLayout
is able to exist on top of it
(or anything else, for that matter)
in short I think it's set up to survive the test of time better this way, and community standards and libraries will come and go built on top of it
a
Oh I'm not familiar with the 
Layout
composable - is that a parent of 
Column
and 
Row
and whatnot?
But I have noticed that I actually prefer androids layout setup the most out of every UI library I've used (lifecycle and whatnot is obviously a different story) but I really like the granularity that android layouts got to - Frame/Linear/Constraint really covers basically all of your use cases other than scrollables.
a
well, "parent" is a stretch, 
Layout
is the low-level composable that lets you give it a 
children: @Composable () -> Unit
block and provide a measure/layout algorithm
basically the "algorithm" you provide is just a lambda block that accepts a list of Measurables; measuring each one gives you a Placeable, then you declare a 
layout(myWidth, myHeight) {
block and place all of the measurables in there
so it combines 
onMeasure
and 
onLayout
in the same lexical scope; you don't have to use instance fields to keep info between the two
and it can re-place without re-measuring if sizes of things that influenced the 
myWidth, myHeight
didn't change
I'm pretty happy with the way it's turning out
there's also 
WithConstraints
that lets you compose content based on the layout constraints it receives; something like this is what the Compose RecyclerView-alike is based on
as to not knowing what to reach for, 
Row
and 
Column
rather than a parameterized 
LinearLayout
is easier for me to visually parse, personally, but almost everyone we talk to is confused by 
Stack
meaning 
FrameLayout
- a part of me just wants to 
s/Stack/Frame/
for this and call that part a day
and we have some people on the team who expect the reverse behavior from 
Row
and 
Column
- naming is hard 🙂
a
I'm totally fine with 
Row
and 
Column
and 
Stack
- I also didn't originally parse 
Stack
as being the same as 
FrameLayout
but I think that's just lingering android view terminology that should probably be avoided. I think conceptually 
Stack
makes sense. My question has more to do with like, 
FlexColumn
vs 
Column
vs 
Container
vs etc. Basically there's a lot of layout "primitives" out there in compose, whereas on the RN side you have one (
View
) and in native android you have ~ 3-5 or so core view groups. Honestly it could just be that I'm still internalizing the main layout composables and there's not as many as I'm imagining.
a
There are a lot of them but we're in the process of adapting and paring down. I'd expect some more deprecations and removals over the next few -devNN releases.
👍 2
for example, 
Column
is meant to be able to do all of what 
FlexColumn
was doing by way of using modifiers on 
Column
children rather than the DSL scope of 
FlexColumn
to declare the same things.
6 Views
Open in Slack
PreviousNext
Powered by

kotlinlang

A modern programming language that makes developers happier.

Powered by