a

    alexsullivan114

    2 years ago
    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

    Adam Powell

    2 years ago
    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

    2 years ago
    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.
    Adam Powell

    Adam Powell

    2 years ago
    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

    2 years ago
    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

    Adam Powell

    2 years ago
    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.
    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.