2.x: FlatMap Observable with a Single

[vanniktech]

Often times I have an Observable and want to flatMap all values with a Single.

Imagine having Single<Photo> getPhoto(int user)

if I wanted to flatMap it with an Observable it would look like this:

Observable.range(1, 100).flatMap(user -> getPhoto(user).toObservable())

It does the job however the Single always needs to be converted to an Observable. Are you guys open for a flatMap version which takes a Single or is there any way around this already without the need to convert the Single to an Observable?

[akarnokd]

Possibly; but the overall problem is the combinatorial explosion as you'd need mapping with Maybe, Completable herea nd extend other operators, as @JakeWharton warned about.

[vanniktech]

Yeah I already had this regard in my mind, basically 6 new API calls would need to be created:

Flowable.flatMapSingle()
Flowable.flatMapCompletable()
Flowable.flatMapMaybe()
Observable.flatMapSingle()
Observable.flatMapCompletable()
Observable.flatMapMaybe()

I understand the concern about all of the varieties however personally I feel like this would be a good addition to the public API. Especially since Completable, Maybe and Single already have those flatMap variants. Also with having those special flatMaps one would not need to convert the original Type to an Observable / Flowable anymore.

I'd be happy to contribute to those.

[akarnokd]

Sure. Also could you please add comparative benchmarks?

[vanniktech]

You mean comparing the new methods against the old flatMap(single.toObservable()) plus the other types?

[akarnokd]

Yes.

[vanniktech]

Alright I'll start with Observable.flatMapSingle() though it might take me a while to grasp all of the internals of flatMap

[LalitMaganti]

I'm also working on the idea described in #4584 (at https://github.com/tilal6991/RxJava/commits/2.x) to try and get rid of this combinatorial explosion - this is especially valuable if you find that hand optimizing for every variant turns out not to be worth the effort.

[akarnokd]

The patterns will be very similar but due to the upstream and receiver types, you can't have one implementation.

[LalitMaganti]

I understand - this is more to reduce the fact that all the classes are spread across the codebase without any sharing of implementation. I'm pretty sure we can consolidate code somewhat.

[vanniktech]

Schedule has gotten tighter I don't think I can come up with anything until RC4 (this Thursday)

[akarnokd]

Okay, I'll do them.

[akarnokd]

Done in #4667; It's easy to write them because knowing that there's going to be at most 1 element opens up nice simplifications.

[vanniktech]

Closing via #4667. Thanks once again