It seems like if there was not a user interaction ...

# compose

[Guy Bieber]

It seems like if there was not a user interaction (i.e. updating initial state from the server instead of a user action) the values don’t update. I use the same model for different controls and some work / some don’t.

[Leland Richardson [G]]

just a shot in the dark, but usually when i see people run into this problem it’s because you’re actually creating a new model/state every time you recompose.

For instance:

@Composable fun Counter() {
  var count = mutableStateOf(0)
  Text("Count: ${count.value}")
  Button(onClick={ count.value++ }) {
    Text("Increment")
  }
}

[Leland Richardson [G]]

ie, what you really want is:

@Composable fun Counter() {
  val count = remember { mutableStateOf(0) }
  Text("Count: ${count.value}")
  Button(onClick={ count.value++ }) {
    Text("Increment")
  }
}

[Leland Richardson [G]]

which is the same as

@Composable fun Counter() {
  val count = state { 0 }
  Text("Count: ${count.value}")
  Button(onClick={ count.value++ }) {
    Text("Increment")
  }
}

[Leland Richardson [G]]

so perhaps you’re constructing a model each recompose and you’re only seeing the initial state each time

[gildor]

Had the same issue when just started play with compose. Should usage of eager version of mutable state be discouraged?
state { defaultValue } even shorter and avoid such accidental introduction of state recreation

Or there is some important use case for mutableStateOf?

[Leland Richardson [G]]

mutableStateOf can be used outside of composition, which is an important use case. This is a common source of confusion though so we are throwing around ideas of how to make it less likely to make this mistake

[gildor]

ahh, right, so state is composable itself and cannot be called outside of composable function

[gildor]

Maybe lint check? because usage of it from composable function most probably a mistake

[Leland Richardson [G]]

yep, this is at a minimum something we will do