Considering a case of

LazyColumn

- let's say i have a conditional statement inside my composable - which can end up making a structural change

if(loading) {
 // ShowLoader 
} else { 
  LazyColumn {}
}

Every-time there is a

State<>

mutation of

loading

being

false

or

true

compose compiler will wipe away(remove it from the composition tree) and re-add it again and

LazyColumn

can end up composing it's all items again. One simple scenario could be - when clicked on item to delete •

isLoading

is set to true, removing

LazyColumn

from the composition tree • once any item is updated (say a server call!), when

isLoading

is set to false,

LazyColumn

gets added again This is mostly an anti-pattern i believe and i am ending up losing the

LazyColumn

Positional with key Memoization

capability in this case and in scenarios like this, this should not be part of a conditional logic?

I ended up using

rememberSaveableStateHolder()

for a similar scenario, it allowed me to keep the state of certain components even if they were "off screen" at times, as long as the key specified remained the same.

Ohh okay sure, i will explore

rememberSaveableStateHolder()

Other handling could be, for composables like these, let them always be part of composition tree - as in do-not put it inside

if/when

or any kind of conditional logic. Next time if

LazyColumn{}

state mutates, it will just recompose the affected item or re-creates the required ones, instead of going through the initial composition every-time

isLoading

mutates.

Building on top of that, perhaps it would be viable to have an item in your LazyColumn that represents loading (and have it extend to full height)? I believe that will sort this out as well. In either case, good luck 🙂

Yea, most apps don't completely remove the list from the ui when loading/reloading data. Is that actually what you want to do? If so, you could simply not place the lazy list when you want to hide it, to keep its composition and state around.