Orhan Tozan
10/13/2020, 1:22 PMStateFlow<T>
mapping a planned feature? Right now I stick with Flow instead of StateFlow<T> because it stops me from doing something like this:
// Example 1
val name: StateFlow<String> = ...
val greeting: StateFlow<String> = name.map { name ->
"Hi, $name!"
}
// Example 2
val a: StateFlow<Int> = ...
val b: StateFlow<Int> = ...
val sum: StateFlow<Int> = combine(a, b) {a, b -> a + b }
Jan Skrasek
10/13/2020, 1:24 PMOrhan Tozan
10/13/2020, 1:38 PMZach Klippenstein (he/him) [MOD]
10/13/2020, 1:53 PMOrhan Tozan
10/13/2020, 2:02 PMZach Klippenstein (he/him) [MOD]
10/13/2020, 2:49 PMshareInWithoutScope
operator:
val upstream = flow {
emit("starting")
delay(1000)
emit("finished")
}.shareInWithoutScope()
// First collector
launch { // this: scope1
withTimeout(500) {
upstream.collect {}
}
}
// Second collector
launch {
// this: scope2
delay(250)
upstream.collect {}
}
In order to collect upstream, the operator needs a scope to collect in. If this collection happens lazily, it could use the scope of the first collector (scope1
). Then the second collector starts collecting in scope2
after 250 ms, which is fine. Then, at 500 ms, scope1
gets cancelled – but scope2
is still collecting, so the upstream collector needs to keep running. So sharing operators can’t rely on their downstream collector scopes to manage the shared collection.map
operator on StateFlow
that preserves the StateFlow
type itself, see the discussion on this issue: https://github.com/Kotlin/kotlinx.coroutines/issues/2081Orhan Tozan
10/14/2020, 3:31 PMZach Klippenstein (he/him) [MOD]
10/14/2020, 5:23 PM