Why do Subject operators work this way?

[axtgr]

I'm asking for the reasoning rather than a technical explanation. I understand that subject operators return an AnonymousSubject which passes events to the source. This seems very confusing, as I'd expect the derived values to be one of two things:

• An observable as a read-only interface to the source
• A full-fledged subject subscribed to the source

It is also very similar to the common mistake with mutable data structures:

let a = new Rx.Subject();
let b = a.map(x => x * 2);
a.next(1);
b.next(2);

let q = [];
let w = q;
q.push(1);
w.push(2);

I don't see a good reason for introducing such behavior, but I'm pretty sure it has been discussed before. Sorry for raising this question again, but I couldn't find any public explanation. I believe it belongs in the manual, because the first time I encountered this felt like triggering a mutability booby trap.

[aluanhaddad]

Interesting, I never noticed that. For what it is worth in the original .NET CLR Observables, and continuing through the most recent version, Subjects behave as you seem to expect. i.e.

var subject = new BehaviorSubject<int>(1); // BehaviorSubject<Int32>
var projected = from n in subject select n * 2; // IObserable<Int32>

Now this may be simply due to the practical (lines of code) limitation based on the nature of extension methods in C#/VB/CLR (in other words there are no HKTs), and thusly not as revealing of intent, but I doubt it.

Looking at RxScala it returns Observable[Int] the analog of IObservable<Int32> and Scala does not have the same limitations as C# with respect to propagating types. This can be observed in the core language's use of an implicit cbf parameter throughout their entire collection library to map sets to sets, lists to lists and so on, but it was not applied here.

[kwonoj]

Though it is not identical, I'd consider this as similar to #2391 . Best recommended way is to refer type definition to see if it's expected or not. Note I'm not saying you should use TypeScript and it can be bit annoying to refer type definition - it's just way to confirm it with status quo of implementation.

Aside of those, for this specific matter it is interesting perspective how we'd like to deal with inherited variant of Observables. For example, if you have custom extended Observable (like ActionObservable in redux-observable) you'd probably want to carry forward specific method into operator chain, while for Subject it is inherited from Observable probably we don't want to carry forward nature of subject.

[martinsik]

I guess the same situation is when the .subscribe() method in fact returns an instance of Subscriber instead of Subscription as you'd expect from the type definitions: https://github.com/ReactiveX/rxjs/blob/master/src/Observable.ts#L93

This allows me to call methods directly on the observer and do very weird things such as the following:

let subscription = Observable.timer(0, 1000)
  .subscribe(val => console.log(val));

subscription.next('Hello');

setTimeout(() => {
  subscription.next('World!');
  subscription.complete();
});

This prints to console:

Hello
0
World!

Actually, I've seen this on StackOverflow where the poster was asking why his Observable chain doesn't work. Until then it never occurred to me that this is even possible :).

Update: mentioned also in #2314

[aluanhaddad]

That's definitely a little scary that something as basic as Observable.timer returns something so malleable. I wonder if it's not a performance trade-off.

[Dorus]

I would like to add here that i've seen people rely on this behavior on webSocketSubject. I.e. src = Rx.Observable.webSocket().map(...); src.next(...);.

Ps. My first reaction here was... Yikes!

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.