Suppose I have the following composable ```@Compos...

# compose

[undermark5]

Suppose I have the following composable

@Composable
fun MySectionedLazyList(viewModel: SectionedListViewModel) {
    LazyColumn(modifier = Modifier.fillMaxSize()) {
        viewModel.section1?.let {
            items(items = it.items, key ={it.key}) {
                Item1(it.data)
            }
        }
        viewModel.section2?.let {
            items(items = it.items, key ={it.key}) {
                Item2(it.data)
            }
        }
        viewModel.section3?.let {
            items(items = it.items, key ={it.key}) {
                Item3(it.data)
            }
        }
    }
}

and I would like to scroll to the 5th item in section3, but I don’t know it’s index, only it’s key, how would I accomplish such a task? Everything I’m seeing requires use of the item index, which while I could compute, it would be much easier if there was a way to scroll to an item with a specific key rather than just based off index.

Is this just functionality that I’d have to implement myself?

[undermark5]

or, is the real answer to combine everything to be displayed into a single list instead? That doesn’t seem ideal because then I’ve got to build in logic at the view level to determining which composable the data is supposed to get passed to (multiple dispatch would kinda eliminate that need, but is not something that Kotlin currently supports, and likely never will)

[ephemient]

https://issuetracker.google.com/issues/274658450

[undermark5]

I literally just made that issue a few minutes ago.

[ephemient]

haha, I see

[ephemient]

well, the closest workaround I can think of is to wrap LazyListScope with your own that tracks the keys/indices

[undermark5]

Yup, that is what I thought of as well, this original problem was actually brought up by a coworker 6 months ago and I proposed the same solution then as well, but had forgotten about that until I ran into the issue today and the coworker brought it up that we had previously discussed that very solution. At the time it was deemed to be too much effort and didn’t provide enough value to be worth the development time, but maybe now that is different.

[ephemient]

untested but perhaps

fun LazyListScope.logKeys(content: LazyListScope.() -> Unit): List<Any> = buildList {
    object : LazyListScope by this@logKeys {
        override fun item(key: Any?, contentType: Any?, content: @Composable (LazyItemScope.() -> Unit)) {
            [e-mail](key ?: [e-mail])
            [e-mail](key, contentType, content)
        }

        override fun items(
            count: Int,
            key: ((index: Int) -> Any)?,
            contentType: (index: Int) -> Any?,
            itemContent: @Composable (LazyItemScope.(index: Int) -> Unit)
        ) {
            [e-mail](List(count) { key?.invoke(it) ?: ([e-mail] + it) })
            [e-mail](count, key, contentType, itemContent)
        }
    }.content()
}

var keys by remember { mutableStateOf(emptyList<Any>()) }
val state = rememberLazyListState()
LazyColumn(state = state) {
    keys = logKeys {
        items(...)
    }
}

state.scrollToItem(keys.indexOf(key))

[dewildte]

is the real answer to combine everything to be displayed into a single list instead?

I suggest doing this.
I did this on a project I am working on and it’s reliable.

[dewildte]

Representing every item in the list as it’s own item allows for doing interesting things too.
Like scrolling to a specific divider for example.
Or even a specific item in a specific section or a specific section.

[dewildte]

It’s flexible at the cost of some infrastructure.

[dewildte]

Like most flexible things.

[dewildte]

You could add support later for the indicator like Slack has too!

[undermark5]

@dewildte so I take it then in your composable you have a when block that is in charge of dispatching to the correct composable for each item in the list? I’d prefer to keep the logic out of the view, but I’d also like to keep the view out of the data class, and I think both of those things are at odds with each other. Which comes back to my previous comment about wishing Kotlin supported multiple dispatch as then the logic is handled by the language rules.