Closed rgbkrk closed 8 years ago
As for 1, we do need to be able to dispose of the underlying socket, via onCompleted
. It does make sense to be a subject then. It just shouldn't try to send messages across. Tempting to make subj.close = subj.onCompleted
, just like subj.send = subj.onNext
. Carries the intent better, which is my answer to (2).
For (3), I'm wondering if there is a better approach to handling these from Rx. I technically want to be able to use the Observer
without making a subscription to the Observable
.
Technically theStill have to rely oniopub
should not be a subject. It should only be anObservable
.onCompleted
, still a subject.I totally cheated and declaredNow we're using RxJS 5 / ES7 Observable parlance.subj.send = subj.onNext
to fit our intent rather than RxJS's parlance. I like this better so people can writeshell.send(payload)
. Somebody once told me that adding props at runtime is a performance drag. Once I see that being an issue, we can adapt it.Since these get tied together as subjects, the user is required to subscribe to any they want toOk, this is still an issue. Sweep it under the rug!onNext
ahemsend
on.