One Off the Slack: I Heard You Like Columns...

Colton Idle asked:

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?

After all, a column is a column is a column… right?

Zach Klippenstein pointed out that there is a matter of weight:

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.

Or, as Google’s Romain Guy pointed out, it is roughly analogous to comparing a LinearLayout and a RecyclerView (with a LinearLayoutManager, presumably), or comparing LinearLayout and ConstraintLayout:

…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

Colton then drew a real-world analogy:

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.

It’s not merely that a you do not need a sledgehammer for, say, hanging a picture. Trying to pound in a small nail with a sledgehammer may well put a large hole in your wall. LazyColumnFor() is not just more powerful than Column() — it is more expensive. Joost Klitsie pointed out one:

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

So, a Column() can go in places where a LazyColumnFor() cannot.

For the same level of expense, a more-powerful component is better than its less-powerful counterpart. However, cost differences can be very important in their own right, and so having less-expensive (albeit less-powerful) constructs can be important, even if they seem redundant on the surface.

---

Read the original thread in the kotlinlang Slack workspace. Not a member? Join that Slack workspace here!