Why are we getting indexed variants for lazy composables instead of adding index to the existing one...

# compose

[Ricardo C.]

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

[Leland Richardson [G]]

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

[Ricardo C.]

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

[Leland Richardson [G]]

that is fair

[Leland Richardson [G]]

we are starting to think of Lazy* as more of a lazy for each type thing

[Leland Richardson [G]]

for instance

Column { for(item in items) { Item(item) } }

is equivalent to

Column { items.forEach { Item(it) } }

And we are thinking that ends up being semantically very close to

LazyColumnFor(items) { Item(it) }

[Leland Richardson [G]]

i’m sure team would appreciate your feedback though and might have more to say on it. cc @Andrey Kulikov and @Ryan Mentley (not sure if Mihai is in this slack yet?)

[Ricardo C.]

some sort of

items.columnForEach { Item(it) }

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

[Ricardo C.]

it’s probably my mental model that is wrong, but I see the widgets as this big things. like were the views. and having a different view just because one callback had one more parameter wouldn’t feel right

[Leland Richardson [G]]

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

[Leland Richardson [G]]

yeah in compose the weight of an overload seems much less

[Andrey Kulikov]

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

[Ricardo C.]

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!

[Zach Klippenstein (he/him) [MOD]]

@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.

[Andrey Kulikov]

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

[Adam Powell]

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

[Zach Klippenstein (he/him) [MOD]]

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)

[Leland Richardson [G]]

👍

[Leland Richardson [G]]

google doc culture is hard to get around at google. it would be great if we marked a bunch of the design docs public (can we do that retroactively?)

[Zach Klippenstein (he/him) [MOD]]

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.

[Leland Richardson [G]]

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.)

[Leland Richardson [G]]

i think we’ve become more amenable to this over time though so it might be a good time to bring it back up

[Leland Richardson [G]]

esp. if the content is “dead” and timestamped notes etc.

[Adam Powell]

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 😅

[Leland Richardson [G]]

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

[Adam Powell]

oh for sure