also how to let the messageId visible? I dont want...

# rx

[ursus]

also how to let the messageId visible? I dont want to emit pairs everywhere

[gildor]

Pretty easy to rewrite with coroutines rxSingle builder

[kioba]

use flatMap, it lets you use the messageId.

[alexsullivan114]

I don't want to emit pairs everywhere

[alexsullivan114]

flatMap won't fix that

[alexsullivan114]

chaining data across multiple operators is a pain point in Rx

[ursus]

@gildor If I'd use the coroutines adapters, then I have coors and rxjava both at runtime, does that mean I have 2x the threadpools (dispatchers + schedulers) or can they be shared?

[gildor]

You can create dispatcher from scheduler and use it to create coroutine
https://github.com/Kotlin/kotlinx.coroutines/blob/master/reactive/kotlinx-coroutines-rx2/src/RxScheduler.kt#L16

[gildor]

But in general sure, it's quite a big change and it make sense if you are going to use coroutines, it improves usability in some cases (like this), but you should concider does it make sense for you project or not, after all you can write it with Rx

[ursus]

yea, I'll suffer the flatmapping of singles until Flow is ready so I can have proper Observable alternative,that it vital for me

[gildor]

In our project we use Observable/Flows for streams and use coroutines and happy how coroutines work for such Rx builders, in many cases it simplifies code a lot

[gildor]

Also, in this case you even don't need observable/flow, it's just a suspend function and coroutines work perfectly for this

[gildor]

So not sure why do you need flow for this case

[ursus]

you dont, but need reactive code elsewhere all over the app, and I kind of dont want to have both rxjava and coroutines in the app; id rather only have one

[gildor]

I mean this particular sample which you show is not really reactive, just some async call

[ursus]

yes, you're right, flatmapping of Singles is silly, so Im evaluating if I wanna suffer the flatmapping and keep nice Observable else in the app, or have nice async via suspend and then lacking reactivness / unstable Flow

[ursus]

I'll switch to cor + flow once its stable

[gildor]

And of course it's you decision, if you don't want to use coroutines you have to handle such cases using RxJava, and sometimes suffer from not so nice code with all those pairs to pass down of the chain

[ursus]

yea, any idea on when Flow could be stable for production?

[gildor]

We use Rx Observable/Flowable for data flows and do not plan migration to Flow, it looks unnecessary for big existing project

[gildor]

Because migrate Rx to flow will not be easy

[ursus]

isnt Flow direct replacement for Observable/Flowable?

[gildor]

Yes

[ursus]

yea migration is pain, im thinking for new project

[gildor]

But if you already have a lot of Rx code, why would you migrate?

[gildor]

Rx coroutines builders are really nice, also not only for single but for observables too

[ursus]

im not migrating, im just evaluating for future

[gildor]

I just mean that coroutines allow to solve many pain points of Rx, like on you sample

[gildor]

Without requirement to wait for Flow

[ursus]

corrent, sequential async code is way better, but I still need my streams in the app, outside of that sample

[gildor]

You still can use your Rxjava streams

[gildor]

Rx coroutine adapters are great, we use both seamlessly

[ursus]

yea, I didnt know you could share threadpools, ill think about it thanks

[gildor]

I also don't think that threadpools is a big problem, for sure you can optimize some hot points using them, but imo for most code it's unnecessary premature optimization

[gildor]

You can also configure default dispatchers