I find myself doing a lot of nested Columns inside...

# compose

[Colton Idle]

I find myself doing a lot of nested Columns inside of Rows and vice versa kinda like LinearLayout horizontal and vertical in Android view land.

Having a deep enough heirarchy was viewed as a possible perf issue and so something like constraint layout was helpful. In compose, do I have to worry about having really nested Cols and Rows?

[jim]

https://xkcd.com/1691/

[Colton Idle]

Agreed. But as a general sense I think it's just helpful to know if it's a problem to look out for on the horizon. Similar to very early days of android and overdraw. 5+ years ago I use to look for easy wins in the overdraw department, but now from what Romain has said... with some optimizations and such it's really not that big a deal. So I'm just curious about the same thing for Cols and Rows.

Is the potential of a problem completely erased in Compose?

[Colton Idle]

@Alexjlockwood I swear I just opened up twitter and I saw your question on my timeline. lol. Curious for the answers there too.

[jim]

I don't think there are any compose applications that are yet big enough to have any real data on this question. When you measure a problem, and can back it up with data, then we can work together on options to solve the problem. Until then, the only thing we know for sure is that nesting is much faster with Compose than it was with Android Views.

[Alexjlockwood]

yeah probably an open question i guess. i havent needed to use constraint layout at all yet but maybe i will some day 🤷

[Colton Idle]

I hope I don't have to. There have been legit cases to use CL for me because of some crazy crazy difficult designs that literally made no sense but I always felt like those layouts were miserable and unpredictable from that certain design team. Things that can logially be laid out in rows and cols just seems to make sense for all parties involved (eng, design, product, qa, and the user themself)

[Adam Powell]

there are several things we did with compose's layout system that avoid some of the view system's layout pitfalls. Measuring a child multiple times to determine its final size can lead to exponential complexity. View implementations expect the authoritative/final measure to always come before layout to configure mutable state for later, so if you measure a child several times speculatively, you may have to measure it at its determined size one last time. When a child view requests layout the API doesn't communicate why, and we don't know if that child's measurement affected the parent's size or not, which means we have to re-run more work than we might otherwise need to requesting layouts up the parent chain. These things all combine to defeat a lot of potential caching opportunities; we just have to run more code and repeat the work.

[Adam Powell]

It's incredibly easy to get LinearLayout to measure all of its children more than once; baseline alignment being on by default for horizontal layouts combined with weighted children leads to a bunch of it.

[Adam Powell]

by being flat, ConstraintLayout for views gets to skip a lot of that and make more assumptions internally in analogous ways to Compose establishing a different contract for layouts when you have Compose UI elements inside Compose UI containers. We have more fine-grained invalidation data, we cache more, and we avoid more worst-cases.

[jim]

Which is Adam's way of saying: nesting is much faster with Compose than it was with Android Views. 😂

[Adam Powell]

tl;dr: yes 😄