Add `endWith`

[benlesh]

Frequently while developing with our redux middleware, we find the need to have an operator source.endWith('foo'). Generally, this can be accomplished with a source.concat(Observable.of('foo')), but it's just more verbose.

endWith would be a nice to have for our use-cases at Netflix.

cc/ @jayphelps

[jayphelps]

RxJava calls this concatWith

ReactiveX/RxJava#1176

Personally, I think endWith is more elegant since it's opposite of startWith and more self-documenting, even though Rx gurus should know what concat means, if you're not one it is easier to grok.

Edit: I'm now torn. See #1709 (comment) for good points.

[benlesh]

Rx gurus

Wherever those are. lol.

[benjchristensen]

We called it concatWith since it is literally just an instance method for concat. It is one of many we used this pattern for where we added *With instance methods as siblings to their static counterparts, such as ambWith, concatWith, mergeWith, zipWith allowing chained usage, rather than requiring a new expression with static usage.

In other words, if a.concatWith(b) is done statically, it is concat(a, b): https://github.com/ReactiveX/RxJava/blob/1.x/src/main/java/rx/Observable.java#L4083

However, startWith is also just an instance method for concat, just the order is reversed: https://github.com/ReactiveX/RxJava/blob/1.x/src/main/java/rx/Observable.java#L8022

So, I could see you going either way with the naming. It is odd though if multiple are chained, such as: a.endWith(b).endWith(c) vs a.concatWith(b).concatWith(c). In practice though this is somewhat inefficient to do and should just be turned into concat(a, b, c) so only one operation instead of two has to occur.

So, even if endWith was added to the API, I would still want concatWith (the two are aliases of each other) for the common pattern of zipWith, mergeWith, concatWith, ambWith, etc.

[jayphelps]

@benjchristensen super great points. What happens in RxJava if you chain starts? a.startWith(b).startWith(c)? I imagine pretty much the same as if you do this in RxJS..isn't that just as odd as chaining ends?

[jayphelps]

Seems one deciding factor would be: "are we ever going to add the other "with" operators like zipWith, mergeWith, etc?" If no, I say it's an easy choice in favor of endWith. If yes, we have to either choose to have naming parity between one but not the other, or just have both as aliases; I hate aliases.

@mattpodwysocki I don't see any discussion around this in v4, was there a particular reason it was never added?

[benjchristensen]

..isn't that just as odd as chaining ends?

Yes it is. I've always found startWith odd to use as it is out of order. For example: just(1, 2, 3).startWith(0) results in 0, 1, 2, 3.

One would never write that particular code, so it's more like this:

Observable<T> o1 = ...
Observable<T> o2 = o1.startWith(something);
/// this emits "something" then output from "o1"

But this can be written instead as:

Observable<T> o2 = something.concatWith(o1);

... and that now flows more naturally.

I hate aliases.

I dislike them too, but we've ended up with some in RxJava for better or worse.

are we ever going to add the other "with" operators

I find zipWith/mergeWith/concatWith/ambWith more useful than startWith/endWith and more generic.

[staltz]

I'm definitely agreeing with Christensen here, on concatWith etc. When I first heard of endWith, my first reaction was "probably some very new behavior", but then, it's just concat. We should avoid excess cognitive load of understanding what each of the 100+ operators does.

[benlesh]

I think this has come up before. It might be that we need to make sure concat supports passing non-observable values and lifts them into observables. I don't think it does right now.

source.startwith(42) works. source.concat(42) does not

[jayphelps]

@Blesh Your last comment confuses me, so I want to clarify just in case: RxJava concat instance operator does not accept non-observable values either, which is why it has concatWith to support that use case.

e.g. in both RxJava and RxJS:

source.concat(42)
// type error

I'm not big on overloading concat to consume both observables and values, since then you cannot emit an observable as a value.

[staltz]

I'm not big on overloading concat to consume both observables and values, since then you cannot emit an observable as a value.

Agree

[benjchristensen]

I'm not big on overloading concat to consume both observables and values, since then you cannot emit an observable as a value.

I also agree with this. Same problem in RxJava.

[benlesh]

which is why it has concatWith to support that use case.

I think I was misreading the thread above then... So we're saying concatWith instead of endWith even though, basically, they're the same thing? That's fine. I just know I need an operator to make this more ergonomic