Why does compose have both Column and LazyColumnFo...
# compose
c
Why does compose have both Column and LazyColumnFor? It seems like everyone could just potentially benefit from using LazyColumnFor and getting rid of Column (or putting LazyColumn functionality into Column, and removing Column) could work? I only bring that up because I think I remember reading that @elihart said something along the lines of ~"Airbnb uses Epoxy even for lists that are completely heterogenous because RecyclerView will still only draw what needs to be on the screen which is a net benefit". I think Eli said that when someone asked like if using Epoxy was okay for using on all screens of an app, even the ones that don't even need a RecyclerView. Even taking Elis comments out (in case I'm imagining things) wouldn't just having a single abstraction for laying things out in a list be good for simplicity, and the list just knows how to "recycle" things if needed? Basically, theoretically wouldn't every list benefit from being in a RecyclerView/LazyColumnFor?
z
My understanding is that
Column
is extremely cheap, even compared to
LazyColumnFor
, because it works in the same composition and is just a really straighforward layout, unconcerned with scrolling, gestures, animations, etc. Because it’s so lightweight, you can use it to construct more complicated layouts by nesting columns of small numbers of items, combining with other simple layouts, etc. The
LazyList
components have a lot of internal code to track scroll position, manage fling animations, and they use subcomposition which involves creating a whole other slot table. Another example is a CL that just landed, I believe, that automatically creates a separate layer for each child of a LazyList, which I think is an optimization that makes sense for scrolling things but if you’re just using a column to stack two text labels on top of each other would be very much overkill. I’m sure google has benchmarks for all of these somewhere, so i’d be curious to see if this is true, and if so, what the performance difference actually is for small numbers of children. That said, I could see more of an argument for dropping
ScrollableColumn
in favor of the lazy ones, since it seems much more similar to them in spirit.
r
The same answer applies to a
LinearLayout
vs a
RecyclerView
☝🏼 5
a
Also, doesn't scroll bars for example work differently?
c
@romainguy just to clarify. When you are saying "answer" do you mean @Zach Klippenstein (he/him) [MOD]s answer?
r
Yes
👍 1
In a way it’s similar to
ConstraintLayout
vs other layouts
You could use only
ConstraintLayout
But even if there are no measurable performance benefits, using the simpler layouts/widgets can make the code easier to read/maintain and it also conveys an intent more clearly
c
True. I figured that this would be the answer but was just curious if it was ever a thought to kill off Column (or even scrollableColumn like zach said) and instead just use LazyColumnFor for everything. But I guess it's kind of a "right tool for the job" e.g. I don't need a 100lb sledgehammer for a nail in the wall. A regular hammer will do.
j
Also you cannot put a lazycolumn in a lazycolumn, but you can put a column in a lazycolumn, for example if one of your list items require a column then it is handy