Especially since it's used to implement

collectAsState

for `StateFlow`s.

i think that’s the behavior that makes the most sense though. wdyt?

If the initial value changes along with the keys, e.g. in the

collectAsState

case where the flow itself is the key, and the initial value is derived from the flow, then it makes sense. But it’s possible there could be a case where the initial value is not derived from the keys, in which case it might be weird to change the value back to the original initial value instead of just leaving the last state there. I’m not sure which case is more general.

a tangentially related but different bug: https://issuetracker.google.com/180450267

both behaviors have their uses but the requested behavior of resetting to initial can be obtained from the current API by wrapping in

key(...) {}

- doing the reverse if

produceState

were changed would be more cumbersome

(though admittedly the key wrapper gives you a different State instance altogether, which can carry its own issues)

in any case, this is the second time someone has asked for this in the past month or so

So I filed a bug for this https://issuetracker.google.com/issues/181308257 . I got somewhat impatient while writing as it's pretty late where I am. I'll add some more stuff tomorrow once I recharge from work.

It doesn't make the first recomposition with the new key though, it happens after the coroutine dispatch after composition apply

overall, I kind of want to pull

produceState

from the API entirely and observe

Same for all Effect functions

If a snapshot state object is set during recomposition, it behaves like a plain old object - anything that read the old value before it was changed sees the old value, and anything that read the new value after the change sees the new value.

Does setting a snapshot state object before it's read, like doing

value = Initial

as Sean suggested, count as side effect? Specifically, the kind of side effect we're supposed to avoid in composable functions.

"before it's read" -> "before it's read in that composition"

Nvm, I think I just answered my own question lol.

One thing to avoid is, "backwards writes" - reading a snapshot state object in a different recompose scope that appears before the recompose scope it's written in.

If you were to write something like this:

var counter = remember { mutableStateOf(0) }
Text("Count: $counter")
SomeComposable { // @Composable lambda parameter
  counter++ // backwards write!
  Text("New count: $counter")
}

then we're left with a host of bad options for interpreting what you meant in any sort of declarative way

Technically this code asks compose to perform an infinite loop

so don't do that 🙂

Has this been considered or has a decision been made? Given stabilisation is happening soon.

I'll update the bug from above with some of the thinking, happy to elaborate a bit here too

However, I now realise, based on the explanation, that I probably created a ticket for the wrong thing. What about

collectAsState

? It's continuity is handled by the upstream flow, at least for

StateFlow

. Plain

Flow

is somewhat debatable but I'm not fussed about it.

Most of the discussion has been about

produceState

and it makes sense to leave that as-is.

I've resorted to using state objects in my view model instead. It's somewhat awkward but whatever at this point.