Is it normal for an item to recompose when scrolli...

# compose

[allan.conda]

Is it normal for an item to recompose when scrolling a lazy column/grid?
I thought it will just create a new item with only a single composition.

[Stylianos Gakis]

Try turning the item into smth like Spacer(Modifier) and see if it still recomposes. If not, then the problem is in the item itself.
From guessing I’d say it should not recompose unless you’re inside the item reading something related to the scroll-state or some other state which changes while scrolling

[allan.conda]

Well… It still recomposes with Spacer. 😄

[allan.conda]

Code’s like this

itemsIndexed(
        lazyPagingItems,
    ) { index, item ->
        Spacer(Modifier.height(100.dp))
}

[allan.conda]

Going to experiment on a sample project to see if it’s normal behavior

[Stylianos Gakis]

Does this mean that if you have a SideEffect { println("asd") } in the item it’ll also trigger all these times?
I originally thought that the item moving while scrolling should only trigger a re-layout, and not a whole recomposition, it’s surprising if my assumption was wrong.
With that said, do we know what this Layout Inspector is telling us? Do those numbers necessarily talk about recomposition, or also include re-layout?

[Stylianos Gakis]

Alright actually wait a second. I now see that you’ve scroller to item #1000+. I thought that there were recompositions even if you were scrolling a tiny bit up and down.

With this information now, I am guessing this is what’s going on:
The LazyList is trying to re-use some composable under the hood and as the things go into and out of the screen it takes the old composable, and reuses it to put the new information inside of it. The Layout then sees that composable as still the same item and increases this number by 1. Now this behavior is not weird since a new item is coming into the screen which is lazily loaded, and for it to show the new information then yes, there will be a need to recompose.
So I don’t think this is alarming at all, it’s simply the Lazy column doing it’s work. Imagine it like as if it was a RecyclerView reusing ViewHolders. These items you see inside the Layout Inspector are the ViewHolder and the # next to them is how many times they’ve been re-used so far.

[Stylianos Gakis]

Now is this confusing and should the Layout Inspector show this interaction somewhat differently? Maybe yes?
Might be impossible for it to differentiate between a recomposition of these two cases
1. I am a new item, I am coming into the view since I’m being scrolled into
2. I am an item and I am actually recomposing now, nothing to do with the lazy layout
If someone could confirm my assumption here that’d be awesome btw 👀

[shikasd]

I am not exactly sure how recomposition of the subcompose layout shows up in the inspector, but if it ~10 subcompose layouts that are recomposing, it should be about right