I'm still using rx as I need it to be cold most of...
# coroutinesp
Paul Woitaschek
10/30/2018, 7:07 AMI'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?
j
Jonathan
10/30/2018, 8:42 AMFor me it is the opposite, I favor channels, because I find Rx too complicated😁 And I can always rewrite a
val observable: Observable<T> = ...fun openSubscription(): ReceiveChannel<T> = ...p
Paul Woitaschek
10/30/2018, 9:13 AMMy 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.
d
darkmoon_uk
10/30/2018, 1:25 PMHi 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.
darkmoon_uk
10/30/2018, 1:26 PMIt'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.
darkmoon_uk
10/30/2018, 1:28 PMWhat does excite me about the possibility though, is freeing the business logic from the JVM, which RxJava currently ties it to.
j
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