https://kotlinlang.org logo
#compose
Title
# compose
a

alexsullivan114

01/10/2020, 7:52 PM
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

Adam Powell

01/10/2020, 8:14 PM
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

alexsullivan114

01/10/2020, 8:30 PM
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

Adam Powell

01/10/2020, 9:10 PM
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

alexsullivan114

01/10/2020, 9:22 PM
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

Adam Powell

01/10/2020, 11:35 PM
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.
3 Views