Why are we getting indexed variants for lazy composables instead of adding index to the existing ones? https://android-review.googlesource.com/c/platform/frameworks/support/+/1364679

I wasnt aware of this API addition but I’d guess it would be to follow more closely the

forEach

and

forEachIndexed

kotlin stdlib conventions, following the same reasons those were introduced

That was my guess as well, but it kinda feels repetitive. An extension on a list, it’s okay. But a totally different widget just because of one lambda param, seems too much, idk

that is fair

some sort of

items.columnForEach { Item(it) }

but without being an extension. getting closer to the control flows I guess

one aesthetic reason to have two overloads is it ends up being somewhat ugly if you have to do

item, _ ->

for the lambda every time you use it

hey! thanks for the feedback. The fact is our end goal is to have something like this:

LazyColumn {
    item { Header() }
    items(listA) { ItemA(it) }
    itemsIndexed(listB) { index, item -> ItemB(index, item) }
}

Currently this api is under design. In the meantime we have `LazyColumnItems`(or

LazyColumnFor

as we will probably name it in the next release) which provided a subset of possibilities - only displaying items from one list if we just add index for the callback here in most of the cases when you don't care about the index instead of

LazyColumnFor(list) { Text(it) }

you will have to write

LazyColumnFor(list) { _, item -> Text(item) }

we decided that given the long term plan of having a dsl for items and to make it similar to the language constructs like "forEach" and "forEachIndexed" we will provide an indexed version as a separate function

Thanks for answering! That makes total sense if the endgame is that construct you showed. I can easily remember the composable I have to use instead of having several different variants. Looking forward to it!

@Andrey Kulikov I don’t suppose this design discussion is happening in any public issues or docs? I’d love to be a fly on the wall.

@Adam Powell are we going to have public api design docs at some point? 🙂

yes, as soon as I finish writing them up and get people to at least mostly agree with them 🙂 then I can convert it over from google docs to markdown and just keep it in the repo

I got to peek at a semantics merging design doc a few weeks ago, i’m not sure if that was supposed to happen but it was very interesting 😅 (also cc @Leland Richardson [G] who’s always asking how the external contributor processes can be improved)

👍

Any reason you couldn’t just “Publish” the docs (gives you a link to a snapshot of the doc as static HTML)? I’m pretty sure that hides comments and other potentially sensitive/transient content.

We’ve talked about doing that in the past with some things and it usually devolves into a bunch of concern about various things (maintenance, expectations, etc.)

the volume of docs we've created since compose started is massive, navigating it and determining whether something is still relevant or not is an exercise in archaeology 😅

there are some pretty good ones i can think of though that ppl might find interesting

oh for sure