-
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
lift called with incorrect context #3592
Comments
FYI: I'm working on this issue with another contributor. |
Thanks. I wasn't working on it; I just thought I'd flag it with a detailed issue. Probably should have mentioned that. |
Whats the progress on this issue? The bug is still there. Is there any workaround? |
Is it affecting you? It's not the a bug that most devs should run into. The solution to the second point - a lifted custom observable can explode - is trivial, IMO. All that's necessary is for |
Looked at this today. I truly can't wait to get rid of |
This was fixed as of 7.0. |
RxJS version: 5.5.10 and 6.0.0-uncanny-rc.7
Code to reproduce:
As in #3574, a lifted
Subject
does not behave as you'd expect:And a lifted custom observable can explode:
Expected behavior:
The first repro should print
[1, 2]
to the console.The second repro should not explode.
Actual behavior:
The first repro prints nothing to the console.
The second repro explodes with an error.
Additional information:
The problem is down to
lift
being called with an incorrect context - that is, with something other than thesource
observable asthis
:To understand what's happening with the first repro, if you look at the implementation of
Subject.lift
, you'll see that anAnonymousSubject
is returned. Note thatthis
is passed to theAnonymousSubject
constructor as thedestination
.The implementation of
AnonymousSubject.next
callsdestination.next
if it's defined. Otherwise, it does nothing.The problem is effected because the implementation of
combineLatest
doesn't pass the source - theSubject
- as the context for thelift
call; it passes another observable and that observable has nonext
method, so nothing happens whennext
is called.The second is simpler. The observable used as the
this
context has nopath
property, so the constructor explodes with an error, aspath
is not astring
.The first repro is pretty much an edge case, but the second is - IMO - more of a potential problem, as it means that some operators cannot be used with custom observables unless said custom observables either don't implement
lift
or implement it in such a way that it's indifferent to thethis
context.Interestingly, all of the operators that exhibit the problem were - IIRC - candidates for being removed in favour of their namesake observable factory functions.
The text was updated successfully, but these errors were encountered: