I m still using rx as I need it to be cold most of the times kotlinlang #coroutines

I'm still using rx as I need it to be cold most of the times and I find channels too complicated. Are there other stream abstractions built upon coroutines?

Jonathan

10/30/2018, 8:42 AM

For me it is the opposite, I favor channels, because I find Rx too complicated😁 And I can always rewrite a

val observable: Observable<T> = ...

to a

fun openSubscription(): ReceiveChannel<T> = ...

Paul Woitaschek

10/30/2018, 9:13 AM

My app is really reactive. I have a lot of combineLatest and switchMap operators and observables that are shared and hold data as long as there are subscribers and drop data when the last observer unsubscribes. My approaches with produce / select ended up with really complex code.

darkmoon_uk

10/30/2018, 1:25 PM

Hi Paul, I'm in a similar boat: my current project, and the last one, both make extensive use of Rx features to run some complicated UI flows.

It's actually proven a great library to handle the complexity and I"m not ready to give up these tools any time soon - so to that extent I can't get very excited about coroutines until there is a relatively direct Rx equivalent built on top of it.

What does excite me about the possibility though, is freeing the business logic from the JVM, which RxJava currently ties it to.

Jonathan

10/30/2018, 4:36 PM

"My app is really reactive. I have a lot of combineLatest and switchMap operators and observables that are shared and hold data as long as there are subscribers and drop data when the last observer unsubscribes." -> Same for me. It was actually a nightmare before migrating to channels. With RxJava you quickly end-up with complex nested flatMap or flatMapSingle. We sometimes spent hours to understand just 5 lines of a complex Rx observable. Channels are very handy, since we can arbitrarily suspend anywere.

3 Views

#coroutines Join Slack