kotlinx.coroutines
kotlinx.coroutines copied to clipboard
Kotlin
Remove @FlowPreview on `(() ->T).asFlow()` and `(suspend () -> T).asFlow()`
I notice @FlowPreview has been removed on all extensions ###.asFlow() except () -> T and suspend () -> T. Can we remove it on them?
We can gradually promote them to experimental.
Our original concern was top-level scope pollution, but it seems like it doesn't bother anyone.
Could you please elaborate on your usages of these extensions?
We can gradually promote them to experimental.
Our original concern was top-level scope pollution, but it seems like it doesn't bother anyone.
What does this answer mean? Can we remove FlowPreview?
Just wanted to share that I added this to my app level build.gradle.kts (inside of android { })
tasks.withType<org.jetbrains.kotlin.gradle.tasks.KotlinCompile>().all {
kotlinOptions.freeCompilerArgs += listOf(
"-Xopt-in=kotlin.RequiresOptIn",
"-Xopt-in=kotlin.OptIn",
"-Xopt-in=kotlinx.coroutines.ExperimentalCoroutinesApi",
"-Xopt-in=kotlinx.coroutines.ObsoleteCoroutinesApi",
"-Xopt-in=kotlinx.coroutines.FlowPreview"
)
}
This allowed me to remove all the annotations in my code without any complaints or warnings from the IDE. When FlowPreview is eventually removed, I can just remove it from here.
It's not clear to me, without the compiler flags... can/should it be removed?
Can someone write some motivation to remove @FlowPreview?
What is the use case?
With annotations like @FlowPreview you actually need to make a justification in the reverse. What is the reason to continue preventing this API from being stable? Ideally every API annotated with it would be revisited at a regular cadence to ensure that each one needs to remain unstable for some valid reason.
It is useful to convert a lambda to Flow, without flow { emit(...) }`.
suspend fun fetchApi(): Response
fetcherFlow
.flatMapLatest { ::fetchApi.asFlow() }
.collect { ... }
It is useful to convert a lambda to Flow, without
flow { emit(...)}`.suspend fun fetchApi(): Response fetcherFlow .flatMapLatest { ::fetchApi.asFlow() } .collect { ... }
For this particular snippet, I'd argue that you can use mapLatest which accepts a suspend lambda rather than converting the suspend lambda into a one-shot Flow. 🤷♂️
@mhernand40 of course, since it is a simple demo. When we use flatMapXXX, we usually transform the input flow to another flow...
suspend fun fetchApi(): Response
fetcherFlow
.flatMapLatest {
::fetchApi.asFlow()
.map { LCE.Success(it) }
.onStart { emit(LCE.Loading) }
.catch { emit(LCE.Error(it)) }
}
.collect { ... }