-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support optional selector for publish / multicast #1659
Conversation
@kwonoj what were the perf changes for this addition? |
I haven't observed noticeable regression between this changes to master, but current master itself shows some interesting numbers on my machine master, without this PR
may possible
I've added couple of commits for micro perf test as well. |
@kwonoj it's probably the new implementation. In Rx4, I haven't dug into your implementation yet, but this was one of the primary reasons this functionality wasn't reintroduced immediately. |
@@ -2,7 +2,7 @@ | |||
import {Observable} from '../../Observable'; | |||
import {multicast, MulticastSignature} from '../../operator/multicast'; | |||
|
|||
Observable.prototype.multicast = multicast; | |||
Observable.prototype.multicast = <any>multicast; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems like a smell. Why do we need to do this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To support different signature multicast(subject)
/ multicast(factory, selector?)
.
As similar to other operators have different signatures mergeMapTo
/ add/mergeMapTo
if there's completely different two signatures, can't be assigned into prototype directly since function definition is single, polymorphic.
I've added a few comments, and pointed out one area I can see there might be a perf bottleneck. |
d071f1d
to
b6fca2d
Compare
Updated PR per suggestions. One thing about static |
Yeah, we ran into this with |
I've tried to apply similar practices as Basically what need to be done is (in pseudo) class Observable {
static multicast(subjectOrSubjectFactory: Subject<T> | (() => Subject<T>))
: ConnectableObservable<T>;
static multicast(SubjectFactory: () => Subject<T>,
selector?: (source: Observable<T>) => Observable<T>): Observable<T> {
}
} function signature overloading in /cc @david-driscoll also for visibility / tips. |
@kwonoj how is perf after the change? |
Where is @jayphelps with his 5th element "multicast" meme? |
Numbers with current changes are below.
|
@kwonoj I think we can merge this as-is and circle back to perf. I have a few ideas. |
By the way, I know it's kind of late, but I just remembered that this should also be done for |
super(); | ||
} | ||
|
||
protected _subscribe(subscriber: Subscriber<T>): Subscription { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kwonoj shouldn't this really be done with an operator? Why introduce another Observable type?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't have strong reasoning behind this, actually. So suggest to remove this observable type?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, it'll make the ConnectableObservable changes I'm working on easier to integrate.
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. |
Description:
This PR updates behavior of
multicast
andpublish
as well, support optionalselector
functions can be supplied.Related issue (if exists):
#1629
_Note_
As I'm not frequent user of
publish
/multicast
, have gut feeling this PR might be conceptually incorrect at all. Please feel freely point out / or close PR if this isn't correct approach.