Hi all, is there any thing bad with a `collectIn`extension on Flow?

inline fun <reified T> Flow<T>.collectIn(scope: CoroutineScope, collector: FlowCollector<T>): Job {
    return scope.launch {
        collect(collector)
    }
}

It is so obvious, that I was thinking there must be something fundamentally broken if it is not part of the coroutines library.

are you looking for

launhcIn

? https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines.flow/launch-in.html

no. I am looking for a terminal operator.

launchIn

is terminal. Usually this is done via `onEach`+

launchIn

.

Yes, I am aware of this pattern but would prefere a ‘terminal background collector’. To have the collector actually at the end of the operator chain:

flow
.map {
   ...
}
.collectIn(scope) { value ->
   consume(value)
}

since your operator is similar to

launchIn

, there is nothing wrong with it. The KotlinX Coroutines lib typically goes with minimal APIs, so if you need a function like the one you mentioned, you can write it yourself for your project

@stojan yes, I can. That’s why I asked

is there any thing bad with a collectIn extension on Flow?

And explained:

It is so obvious, that I was thinking there must be something fundamentally broken if it is not part of the coroutines library.

So I take your answer to mean ‘it’s fine, library just decided to go another way’ ^^^ This is what your first sentence says

APIs with this shape tend to prevent people from learning to think in suspend if they're new to it and have an Rx background. It's a useful utility if you know what you're doing, but newcomers tend to misread this code:

foo.collect {
  doStuff(it)
}

bar.collect {
  doOtherStuff(it)
}

and they assume the above runs the two collections concurrently rather than sequentially. Reinforcing that assumption from Rx prolongs that confusion

I've found the opposite. When you give people an operator that does what they want, they use it instead of misusing other operators. I've seen

onEach

mistaken for a terminal operator as often as I've seen

collect

mistaken for a concurrent non-suspending operator. Even knowing the API, It's easy to miss the

launchIn

just as basically a typo (which is what led me to always creating my own versions of

collectIn

operators). It's also odd since from my experience,

collect

is rarely useful. Most `Flow`s that I use never complete.

StateFlow

,

SharedFlow

,

callbackFlow

wrapping addListener/removeListener APIs, Room generated `Flow`s. 99% of the time I use my own

collectIn

.

collect

is front and center in the docs, but in practice for me, it's been something of a fringe use-case only really useful in creating my own custom operators here and there.