I've read Zach K blog posts on the topic but I'm still encountering a situation that I can't seem to untangle. Essentially I have a list of items. This list is a mutableStateList. Every item could also have a single property that is also mutableState. When I update this item mutableState, I don't see the composable recompose. Can anyone spot any egregious issues here?

class ScreenViewState {
  val list = mutableStateListOf<Item>()

and my Item

class ConcreteType(override val type: String = "") : Item {
    var something by mutableStateOf("beep")

then in my VM I call

(myItem as ConcreteType).something = "boop"

My composable always beeps, but never boops.

When you change the underlaying

var

, you doesn’t actually mutate the list. Make your `ConcreteType`’s property not mutable and when you want your composable to recompose,

replace

the value on the list. I think having

MutableList

of

mutableStateOf

can be called “2 degrees of mutability” that has been described by Zach in mentioned blog post

Yeah, that did cross my mind with having a mutable state inside of a mutable list, but I only felt fine with it because Adam Powell (and others) kinda led me towards this path for another similar case where I had a mutable list of people, and each person had a mutable state of "isChecked". And so that use case seemed valid in that thread, and so I could only think that my use case here is valid? Prev thread: https://kotlinlang.slack.com/archives/CJLTWPH7S/p1637203859164500?thread_ts=1637187114.148800&cid=CJLTWPH7S

In the previous example you did this:

vm.state.people.forEach {
    TextButton(onClick = {
    it.selected = true
})

so for each

people

you put

TextButton

, do you do the same in current example? Or maybe you put your items in the

LazyColumn

for example?

Hm. You might be onto something there. In the current example I only do what you see above in the original question. I'm trying to edit directly. What's intersting is that I don't actually technically need the original list to be a mutableStateListOf, so I switched over to

val list = mutableListOf<Item>()

and so that only leaves me with mutableState inside of the ConcreteType and it still does not work.

I’m glad you found where the problem is

It's fine to mutate objects' properties inside a list if those properties are backed by mutable state. I'm not sure how you even managed to get a composable inside a remember function, that shouldn't even compile 😅