Curious if there’s a curated list of articles for ...

# rx

[boyw165]

Curious if there’s a curated list of articles for mapping RxJava examples to Kotlin Coroutines? My company is debating about migration from RxJava to Coroutines, and from my current knowledge level of Kotlin Coroutines, I’m not fully convinced. I feel it’s apple vs orange. What do you think?

[Pascal How]

Sorry I only just saw your message

My company recently went through the migration and we used this library
https://kotlinlang.org/api/kotlinx.coroutines/kotlinx-coroutines-rx2/

There are some strategies we used to do it in phases e.g.
Migrate data and domain layers first to coroutines and wrap the coroutine code in rxSingle or rxCompletable so that they can still talk to other layers that were still in Rx.
We kept the Presentation layer in Rx, because of time constraint and project requirements (Takes too long to change everything in one go)

In some cases it can get ugly and we resorted to having runBlocking in production code, which is not recommended. However, if your app still performs at an acceptable level then it is a valid trade off

[gildor]

In some cases it can get ugly and we resorted to having runBlocking in production code

Curious about your cases

[gildor]

It's not apples vs oranges though, both really similar in many ways and solve the same problems

[gildor]

Flow is direct replacement for RxJava, suspend functions is direct replacement for Completable/Single and also more generic async mechanism

[gildor]

Our app was 100% Rxjava for long time, but we introduced coroutines and in a few years we have almost no RxJava anymore, plan to completely get rid of it this year

[gildor]

I think having RxJava and coroutines, but do not use Flow is acceptable policy too, if you code is highly reactive, kotlinx-coroutines-rx2 helps with combining RxJava and suspend function, but it's even nicer with Flow, but RxJava is great by itself, but for many cases suspend functions just way better and easier to use with Flow

[gildor]

So it really depend on your project. If it very heavy Reactive programming, probably not much point to migrate, a lot of effort and result would be very similar with Flow anyway, but if it mostly about Single/Completable/Maybe, suspend functions are way superior IMO

[Pascal How]

Hey @gildor the reason we had this approach with runBlocking is because of how our code was architected and also timelines for project deliveries.
We wanted to migrate from RxJava to coroutines and we started introducing suspend functions for network calls and repositories.
At the same time we also had several different presenters and use cases still in RxJava. We also had several presenters that could use the same usecase because this is where our business logic is
We needed to balance the amount of time we had for refactoring and still remain on top of deliveries so the hybrid approach worked well for us

During the transition, we had presenters and usecases still using Rx and when the usecases called the suspend function, it was done in a runBlocking block. This allowed the usecases to continue returning an Rx object as usual and not become a suspend function

[gildor]

But it's one line of code to convert suspend function to RxJava primitive, like Single, and opposite direction, to suspend function

[Pascal How]

That’s true. Whenever we could we used the kotlinx-coroutines-rx2 library. This allowed us to wrap suspend functions in rxSingle for example.
Looking back at some old code, I realise that in several cases, we also had functions returning regular objects (none Rx) and internally they were calling suspend function e.g.

fun someFunction(): MyObject {
   runBlocking {
      object.sustendFunction()
   }
}

If we hadn’t used runBlocking, we would need to convert all the functions down the line to suspend functions and launch a coroutine in the presenter.
In some cases it was alright but sometimes the MyObject could be used by several other Presenters and classes

[Pascal How]

One such MyObject example was an Identity object which was required by several method calls 😅