https://kotlinlang.org logo
#compose
Title
# compose
r

Ricardo C.

07/23/2020, 4:30 PM
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
l

Leland Richardson [G]

07/23/2020, 5:07 PM
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
r

Ricardo C.

07/23/2020, 5:10 PM
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
l

Leland Richardson [G]

07/23/2020, 5:11 PM
that is fair
we are starting to think of Lazy* as more of a lazy for each type thing
for instance
Copy code
Column { for(item in items) { Item(item) } }
is equivalent to
Copy code
Column { items.forEach { Item(it) } }
And we are thinking that ends up being semantically very close to
Copy code
LazyColumnFor(items) { Item(it) }
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?)
r

Ricardo C.

07/23/2020, 5:15 PM
some sort of
Copy code
items.columnForEach { Item(it) }
but without being an extension. getting closer to the control flows I guess
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
l

Leland Richardson [G]

07/23/2020, 5:18 PM
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
1
☝️ 1
yeah in compose the weight of an overload seems much less
a

Andrey Kulikov

07/23/2020, 5:21 PM
hey! thanks for the feedback. The fact is our end goal is to have something like this:
Copy code
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
😮 1
👍 2
r

Ricardo C.

07/23/2020, 5:27 PM
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!
z

Zach Klippenstein (he/him) [MOD]

07/23/2020, 7:45 PM
@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.
a

Andrey Kulikov

07/23/2020, 8:14 PM
@Adam Powell are we going to have public api design docs at some point? 🙂
a

Adam Powell

07/23/2020, 8:29 PM
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
🎉 2
🙌 3
z

Zach Klippenstein (he/him) [MOD]

07/23/2020, 8:29 PM
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)
l

Leland Richardson [G]

07/23/2020, 8:56 PM
👍
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?)
z

Zach Klippenstein (he/him) [MOD]

07/23/2020, 8:59 PM
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.
l

Leland Richardson [G]

07/23/2020, 9:01 PM
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.)
i think we’ve become more amenable to this over time though so it might be a good time to bring it back up
esp. if the content is “dead” and timestamped notes etc.
a

Adam Powell

07/23/2020, 9:22 PM
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 😅
l

Leland Richardson [G]

07/23/2020, 9:30 PM
there are some pretty good ones i can think of though that ppl might find interesting
a

Adam Powell

07/23/2020, 9:30 PM
oh for sure
2 Views