Open julioromano opened 1 year ago
@JakeWharton any idea about that?
The immediate clock is a best-effort tool: we can trigger recomposition when the state is dirtied, but it is not possible to guarantee that a recomposition will occur each time the state is dirtied.
Honestly, that MyEvent.Increment
causes two recompositions is more surprising to me here! I would prefer not to, but obviously unit testing Circuit-style presenters does expose you to it...
Adding a delay(1)
in IncrementSuspending
like:
MyEvent.IncrementSuspending -> scope.launch {
anInt.value++
delay(1) // delay(0) or yield() won't do the trick!
anInt.value++
}
Makes it emit 3 items too.
Are you confident it is a limitation of GatedFrameClock
or are we hitting some opaque behaviors of coroutines?
Are you confident it is a limitation of GatedFrameClock or are we hitting some opaque behaviors of coroutines?
Speaking as someone who wrote GatedFrameClock
and maintains Turbine, this is specifically caused by Turbine's internal usage of the Unconfined
dispatcher. If we got rid of that, two increments in a row without an intervening suspension would consistently produce only one item (which is what I would expect to be the case: coalescing multiple state changes into one emission is an important thing Compose does for us)
I'm incrementing an initially 0
MutableState<Int>
twice in a row:myPresenter()
emits [0,1,2].Is this a bug or working as intended? And if it is WAI, how come? I naively thought that in both cases I should expect my presenter to emit [0,1,2].
(running Kotlin 1.8.21, kotlinx.coroutines 1.7.1, compose-runtime 1.4.3, molecule 0.9.0, turbine 0.13.0)