Conceptually, im trying to figure out how many of ...

# compose

[Colton Idle]

Conceptually, im trying to figure out how many of these exact sized items can fit, and only grab those number of items in a forEach loop.

pseudo-code:

val size = 48.dp
val howManyItemsCanFitLeftToRight = getHowManyItemsCanFitLeftToRight(size)

Row(){
    state.myList.takeLast(howManyItemsCanFitLeftToRight).forEach { 
        Box(Modifier.size(size).background(/*Randomized color*/))
    }
}

Ideas if this is possible/ what's the best way of implementing fun getHowManyItemsCanFitLeftToRight(size: Dp) ?

[Kirill Grouchnikov]

That would be a subcompose layout probably

[Colton Idle]

I'm watching

https://www.youtube.com/watch?v=l6rAoph5UgI&t=1s▾

now to get a feel for subcomposeLayout. Seems like subcompose layout lets you build performant layouts. Interesting that they mention boxWIthConstraints is built with subcomposeLayout, because ive heard that you should try not to use boxWithConstraints since it's "heavy"

[Colton Idle]

seems like this will do. maybe not good perf wise. but it gets the job done.

var howManyItemsCanFitLeftToRight by remember { mutableIntStateOf(0) }
BoxWithConstraints(Modifier.fillMaxWidth()) {
    howManyItemsCanFitLeftToRight = (this.maxWidth).div((itemSize)).toInt()
}

[Rick Regan]

I use BoxWithConstraints in a similar manner. It seems to work well.

BTW, (maxWidth / itemSize).toInt() looks cleaner.

[shikasd]

BoxWithConstraints is heavier, because it creates another subcomposition
It is a tradeoff between creating all items at once and then skipping them in measure vs creating a separate composition for some of items and paying a maintenance cost

[Colton Idle]

Thanks all. So it seems like using BoxWithConstraints is subpar in this scenario. I will keep playing around with SubcomposeLayout to try to get the width, but I feel like im in over my head. lol