How can I create LazyColumn in LazyColumn? I get `...

# compose

[chanjungskim]

How can I create LazyColumn in LazyColumn? I get

java.lang.IllegalStateException: Vertically scrollable component was measured with an infinity maximum height constraints, which is disallowed. One of the common reasons is nesting layouts like LazyColumn and Column(Modifier.verticalScroll()). If you want to add a header before the list of items please add a header as a separate item() before the main items() inside the LazyColumn scope. There are could be other reasons for this to happen: your ComposeView was added into a LinearLayout with some weight, you applied Modifier.wrapContentSize(unbounded = true) or wrote a custom layout. Please try to remove the source of infinite constraints in the hierarchy above the scrolling container.

error

[Kirill Grouchnikov]

You can't and you shouldn't.

[chanjungskim]

Hmm then How can I solve this issue?

[mattinger]

Perhaps if you explain what you are trying to accomplish, it might make it easier for someone to give a recommendation for a different way. Nesting scrollable content (in the same axis) generally leads to less than optimal user experience, and it makes it hard for the system to figure out exactly which of the containers you are trying to scroll.

[mattinger]

Also, based on your code, I'm assuming the second function should be "SupplementSearchCard"? If so, there's really no need for the outer lazy column in the first function. There's one item in it. You simply need the content card with the LazyColumn in it.

[chanjungskim]

@mattinger Well, I need to reuse SupplementSearchResultCard So, it will be

LazyColumn{
    items(cardList){ cardContent ->
        SupplementSearchResultCard(cardContent)
    }
}

I'd like to create like nested one.

[chanjungskim]

Actually, I tried,

Colum{
   SupplementSearchResultCard(list)
}

and it solved. but, now I want to do like this.

Colum{
   Text(...)
   OtherCompoableFuncions(...)
   SupplementSearchResultCard(list1)
   SupplementSearchResultCard(list2)
}

It doesn't crash but this make the last card scrollable only in it.

[efemoney]

1. Just dont use LazyColumn
2. Use a Column with toggleable scrolling (ie control the scroll via a flag/modifier from outside)

[efemoney]

So you have:

SupplementSearchScreen(…, scrollEnabled: Boolean = false) {
  Column(
    modifier = <existing-modifier>
      .run { if (scrollEnabled) } verticalScroll(...) else this } 
  )
}

Then you can turn off scrolling whenever that composable is nested andmturn it on when its used standalone

[chanjungskim]

Well, if I don't use LazyColumn, isn't it bad approach for the efficiency?

[chanjungskim]

I removed it and just used forEach and then it works.

[efemoney]

You threw efficiency out the door when you started considering nesting lazy scrolling layouts 🙂

[chanjungskim]

what do you mean???

[efemoney]

Scrollable layouts measure their children with “_infinite height”_, but the scrollable layout itself needs to have the exact size of the viewport (more important in the case of lazy layout to be efficient). So when you nest scrollable nodes, the inner one will get that infinite height constraint meaning for the lazy layout, there will be no laziness, it will just layout all its children as if it had all that infinite space to begin with

[chanjungskim]

What about using sealed class + LazyColumn?
For example,

sealed class SearchUi{
    data class Title(val text: String): SearchUi
    data class SearchBar(val text: String): SearchUi
    data class ACard(val list: List<Card>): SearchUi
    data class BCard(val list: List<Card>): SearchUi
}

and then...

LazyColumn{
    items(searchUi){ item ->
        when(item){ 
            is Title -> Text(item.text)
            is SearchBar -> SearchBar(item.text)
            is ACard -> ACard(item.list)
            is BCard -> BCard(item.list)
        }
    }
}

[chanjungskim]

Then, it will be like a RecyclerView and I guess it will be efficient.

[Kirill Grouchnikov]

The general rule of thumb is - only one scrollable container in the same direction. It makes it simpler to reason about the overall interaction behavior, and it makes it much much simpler to make it work from the implementation perspective - no matter if the UI toolkit provides support for nested scrolling.