https://kotlinlang.org logo
#rx
Title
# rx
u

ursus

06/21/2019, 3:28 PM
also how to let the messageId visible? I dont want to emit pairs everywhere
g

gildor

06/21/2019, 3:29 PM
Pretty easy to rewrite with coroutines rxSingle builder
k

kioba

06/21/2019, 3:39 PM
use
flatMap
, it lets you use the messageId.
a

alexsullivan114

06/21/2019, 3:46 PM
I don't want to emit pairs everywhere
flatMap
won't fix that
chaining data across multiple operators is a pain point in Rx
👎 1
u

ursus

06/21/2019, 3:58 PM
@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?
g

gildor

06/21/2019, 4:02 PM
👍 2
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
u

ursus

06/21/2019, 4:06 PM
yea, I'll suffer the flatmapping of singles until Flow is ready so I can have proper Observable alternative,that it vital for me
g

gildor

06/21/2019, 4:06 PM
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
Also, in this case you even don't need observable/flow, it's just a suspend function and coroutines work perfectly for this
So not sure why do you need flow for this case
u

ursus

06/21/2019, 4:11 PM
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
g

gildor

06/21/2019, 4:13 PM
I mean this particular sample which you show is not really reactive, just some async call
u

ursus

06/21/2019, 4:14 PM
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
I'll switch to cor + flow once its stable
g

gildor

06/21/2019, 4:15 PM
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
u

ursus

06/21/2019, 4:15 PM
yea, any idea on when Flow could be stable for production?
g

gildor

06/21/2019, 4:15 PM
We use Rx Observable/Flowable for data flows and do not plan migration to Flow, it looks unnecessary for big existing project
Because migrate Rx to flow will not be easy
u

ursus

06/21/2019, 4:16 PM
isnt Flow direct replacement for Observable/Flowable?
g

gildor

06/21/2019, 4:17 PM
Yes
u

ursus

06/21/2019, 4:17 PM
yea migration is pain, im thinking for new project
g

gildor

06/21/2019, 4:17 PM
But if you already have a lot of Rx code, why would you migrate?
Rx coroutines builders are really nice, also not only for single but for observables too
u

ursus

06/21/2019, 4:18 PM
im not migrating, im just evaluating for future
g

gildor

06/21/2019, 4:19 PM
I just mean that coroutines allow to solve many pain points of Rx, like on you sample
Without requirement to wait for Flow
u

ursus

06/21/2019, 4:20 PM
corrent, sequential async code is way better, but I still need my streams in the app, outside of that sample
g

gildor

06/21/2019, 4:21 PM
You still can use your Rxjava streams
Rx coroutine adapters are great, we use both seamlessly
u

ursus

06/21/2019, 4:22 PM
yea, I didnt know you could share threadpools, ill think about it thanks
g

gildor

06/21/2019, 4:24 PM
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
You can also configure default dispatchers
2 Views