I know there is a bug where `LazyColumnFor` does not remember things when items are removed and shif...

# compose

[robnik]

I know there is a bug where LazyColumnFor does not remember things when items are removed and shifted. I heard that key(...) provides a workaround. I tried this, but it didn't work:

LazyColumnFor(items = nums) { listNum ->
   key(listNum) {
      val r = remember { Random.nextInt(300) }
      Text("Num: $listNum, remembered: $r")
   }
}

nums is mutable state. When I remove the first item, all the remembered numbers change.

[Andrey Kulikov]

yes, it is not yet supported but in progress. once it is done you will be able to provide your keys for elements which would help to move the state of the item together with the item

[Colton Idle]

Interesting. I always thought that you would have to just lift the state out of the lazy composable.

[jim]

Yeah, or you could do that too, that would also work.

[jim]

Hoisting state out of your lazy composables has a few other advantages. For instance, you can restore that state if/when the item ever returns because the user scrolled back up.

[Colton Idle]

Interesting. Seems like keys for elements would let people shoot themselves in the foot in a way... no? I haven't used compose enough to even really have an opinion here. I'm just thinking about the canonical android interview question that I'm always asked. Create a RV with a list of names and a checkbox next to every name. Seems like the state of whether or not a person is checked should belong to an application and not the view.

[Colton Idle]

Got a 100 and a point up from Jim? Made my month! 😅

[JulianK]

For checkboxes, this may be true. But what about swipable items in a list that reveal additional buttons (delete)? I'd argue that the revealState is something that may belong to the view. For those cases, key() in LazyColumn would be good to have...