Question one thing I struggle with when writing Flutter apps

Question

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

Adam Powell · Answer

Quite a bit of discussion happened around it slightly smiling face

Adam Powell · Answer

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

Adam Powell · Answer

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

Adam Powell · Answer

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

Adam Powell · Answer

and the tooling experience around it

Adam Powell · Answer

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

Adam Powell · Answer

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

Adam Powell · Answer

and `ConstraintLayout` is able to exist on top of it

Adam Powell · Answer

or anything else for that matter

Adam Powell · Answer

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

alexsullivan114 · Answer

Oh I m not familiar with the `Layout` composable is that a parent of `Column` and `Row` and whatnot

alexsullivan114 · Answer

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

Adam Powell · Answer

well parent is a stretch `Layout` is the low level composable that lets you give it a `children Composable gt Unit` block and provide a measure layout algorithm

Adam Powell · Answer

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

Adam Powell · Answer

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

Adam Powell · Answer

and it can re place without re measuring if sizes of things that influenced the `myWidth myHeight` didn t change

Adam Powell · Answer

I m pretty happy with the way it s turning out

Adam Powell · Answer

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

Adam Powell · Answer

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

Adam Powell · Answer

and we have some people on the team who expect the reverse behavior from `Row` and `Column` naming is hard slightly smiling face

alexsullivan114 · Answer

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

Adam Powell · Answer

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

Adam Powell · Answer

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