Do we need to avoid deep "view" hierarchy in compose as we usually do with the native android view system? https://developer.android.com/training/improving-layouts/optimizing-layout

this is a nuanced question, i think. It’s hard to definitively say yes or no. Larger hierarchies will be more work for the layout algorithm to figure out than smaller hierarchies… (which shouldn’t be surprising). That said, we have tried really hard to make it so that the nodes themselves of the hierarchy are not anywhere near as heavy weight as Views are today, so this should not be as big of a deal. Additionally, we have tried to have a principled approach when building our layout system. It is strictly a single pass layout system, and the cooperative style of it (i think) should make things like the

weight

modifier less of a foot-gun than it can be in today’s layout system. Also, the programming model itself will push you towards nesting of composables for abstraction, but not as much towards nesting of layout nodes. This helps raise the ceiling. Overall my suggestion would be to not consider the above recommendation for views as mapping over to compose. @George Mount and @Mihai Popa might have more to add here though.

Really glad that

Layout

actively prevents you from doing multiple measure passes, which makes some of the worse footguns like

LinearLayout

impossible to do. 🎉

@Leland Richardson [G] thank you for answering! Before trying compose I loved working on my old project, now it all seems so boring and full of boilerplates 😂