Can anyone explain what `SubcomposeLayoutState.max...

# compose

[natario1]

Can anyone explain what SubcomposeLayoutState.maxSlotsToRetainForReuse is supposed to do? I have a LazyList-like component where only some children are subcomposed and I'm playing with this value, but I fail to see any effect. What's the metric I should be looking at?

[Andrey Kulikov]

it is used to keep such amount of compositions in cache when first you composed n items, and during the next composition you composed less then n items(or n items with different keys), so instead of disposing we will keep maxSlotsToRetainForReuse compositions active so when we need a composition for a new key next time we reuse it

[natario1]

Thanks Andrey. So in a component that shows a fixed number of items (X) at any time, maxSlotsToRetainForReuse has no effect when scrolling. Whenever a new item enters the visible viewport, another disappears at the other end, and subcomposer will always reuse the disappearing composition for the new one. Right? Assuming its >= 1.

The thing I was trying to achieve is quite the opposite - I want to ensure that at least a certain number of composables are cached. If I see 0-1-2 and scroll to 1-2-3, I'd like 3 to be a fresh composition and 0 be cached, so that when I go back to 0-1-2, 0 it is rebound to the same key. This would be much more efficient at least for my use case.

Is there any way to achieve this? In some way, I think I'm looking for a *min*SlotsToRetainForReuse.

[Andrey Kulikov]

not exactly how you described. so imagine during the first measuring you composed items 0 and 1. then on the next measuring you are planning to compose 1 and 2. 1 will just reuse the composable used for key 1 at the previous step, but for 2 we can’t really reuse the one which was 0 previously as we don’t know for sure that you are not going to also compose 0 after composing 2. it is possible that your intention was to compose 1, 2 and 0. so for 2 we create a new composition. but if maxSlotsToRetainForReuse is at least 1 then after the whole pass instead of disposing unused 0 we retain it in a cache. and then when on a next measuring you will compose 2 and 3 we will reuse the cached composition for 0 for composing new item 3

[Andrey Kulikov]

this logic is not really configurable and I was hoping to come up with a more flexible api for this in the future, but the current shape allowed us to add simple composition reusing for Lazy lists

[natario1]

Right, first scroll goes as you say and from that point on, as long as the count of composed items stays the same, no new compositions are created nor disposed.

I hope for a better API as well . This config. minimizes composition creation/disposal, but in some cases (think of a pager) you want to minimize key-specific initialization like remember(key) { ... }. which can be way heavier. Please let me know if there's a ticket I can follow for this! Thanks 👍

[Andrey Kulikov]

for your use case you can just hoist this expensive state outside of items composable and keep it as a map in some scope which lives longer than the item

[natario1]

Yeah, I don't want to hold it for all items though, should be an interval around the currently visible items, kind of like ViewPager or RecyclerView. I'm thinking to build a prefetcher and precompose() 1-2 items in the scrolling direction and maybe 1 in the other