-
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
feat(join): add join operator #1371
Conversation
I've thought about bit if it's possible to make this without exposing interface Context<T1, T2> {
observable: Observable<T1 | T2>;
subscription: Subscription;
}
class join {
private left: Context<T1, T2>;
private right: Context<T1, T2>;
protected _next(value: Observable<T1 | T2>): void {
(this.left) ? this.right = { observable: value, subscription: null } : this.left = { observable: value, subscription: null};
}
} rough proof of concept can be seen at kwonoj@1e06664, what do you think? since it's rough test code, still few topics I'd like to improve such as
and some others I couldn't think of. |
+clarification : I'm not suggesting to update PR as comment. Just kicking off discussion. Not even sure if innersubscription management is efficiently perform compare to original PR. |
*/ | ||
export function join<T1, T2, D1, D2, R>(right: Observable<T2>, | ||
leftDurationSelector: (value: T1) => Observable<D1>, | ||
rightDurationSelector: (value: T2) => Observable<D2>, |
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.
The type of the duration selector observables should be any
, since the typing doesn't at all matter there. So we don't need D1 and D2, I don't think.
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.
Indeed. I'll remove D1 and D2.
@kwonoj I think I can improve the solution with some of your suggestions. ;) I'll update this PR as soon as I can. Answering some specific parts:
I was not very happy with exposing
The items can be removed in any order depending on duration. The first item added can be the last to be removed, i.e. there is no relation between when the item is added to the list and when it is removed. We could use an array instead, but it'll require searching for the item. Map seems a more approriate solution.
I tried to keep it as similar as possible to how RxJS 4 is handling completion to make sure it behaves similarly. |
I don't have clear visibility on those too. I think you may able to file an issue with compelling usecases. As similar,
In general I agree, that question was just came out of curiosity if it's possible to do so. |
Looks like this will need to be rebased. |
Also, I think I'd like to block this until #1364 is merged. After that you'll need to convert your tests to TypeScript. Cool? |
Sure. No problem. |
Okay, this just needs rebased now, I think. |
I'll update it later today. |
Just updated the PR. Changes:
|
@kwonoj I'm still using the index/id approach but I think it's simpler now with Context. |
I'm still in quite favor of not exposing outerindex completely, but that's purely my own :) change looks ok to me. Once @Blesh approves, I'll check in this. |
@kwonoj I kept using the index/id approach for two reasons:
The first is not a strong argument as it's a matter of taste/style. But the second have performance implications. If the subscription is in the right Map, it'll walk through the whole left Map looking for a subscription that is not there. That said, I have no problem in changing the implementation if you guys prefer not to expose the outerIndex from InnerSubscription. |
@luisgabriel Yes I understand, reason I mentioned it was 'my favor', and not insist to change it :) |
This is a pretty in-depth implementation. It's going to take more than a while to review. Can you please add perf tests? It's important that we make sure this hits the perf numbers well. |
@Blesh sure. No problem. |
Hey, @luisgabriel ... sorry I haven't gotten back to this one yet. Hey, @trxcllnt, can you give this a review if you have the time? |
@Blesh No problem. I didn't have time to add the perf tests yet. I'll add them as soon as a can. |
Sorry, @luisgabriel, this is going to need rebased again. While this PR looks fine to me, the major hold up is I'm looking for someone that actually uses |
@Blesh I'll take some time next weekend to work on this. I have to rebase it and change the interface to accept |
Ping @luisgabriel ... just checking in. |
@Blesh I'm having trouble with the tests after rebasing. I'll try to fix it. |
@Blesh Sorry for the long delay. I'm no sure when I can work on this. So I'm going to close this for now. As soon as I can, I'll revisit this patch and submit a new PR. |
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. |
Closes #1341.