Skip to content
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

fix(PromiseObservable): fromPromise does not accept PromiseLike object #2505

Merged

Conversation

midnight-wonderer
Copy link
Contributor

I can not use Observable.fromPromise with promises from when.
The class is clearly documented that it should accept Promises/A+ spec compliant Promise.
I think the type should be relaxed.

@midnight-wonderer midnight-wonderer changed the title Bug/too strict type checking fromPromise does not accept PromiseLike object Mar 30, 2017
@midnight-wonderer midnight-wonderer changed the title fromPromise does not accept PromiseLike object fix(PromiseObservable): fromPromise does not accept PromiseLike object Mar 30, 2017
@coveralls
Copy link

Coverage Status

Coverage remained the same at 97.68% when pulling 8b20019 on MidnightWonderer:bug/too-strict-type-checking into 3e9d529 on ReactiveX:master.

@kwonoj
Copy link
Member

kwonoj commented Apr 2, 2017

And interestingly we didn't have test cases for this cases as well. @MidnightWonderer , would you mind to update PR to include one test cases for given changes?

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.07%) to 97.612% when pulling a0b2f1a on MidnightWonderer:bug/too-strict-type-checking into 3e9d529 on ReactiveX:master.

@midnight-wonderer
Copy link
Contributor Author

Hi @kwonoj, I am not really sure how to test the changes because they are all about the type declaration itself and not the implementation details.

How about a new class exposes only what defined in PromiseLike interface as in my new updates?
If the test fails it will fail at the transpilation step, not the execution step.

I can't see why the test affects code coverage in any way. (unless you count the coverage inside the spec itself)

@coveralls
Copy link

Coverage Status

Coverage remained the same at 97.612% when pulling 7d04f24 on MidnightWonderer:bug/too-strict-type-checking into e14fa8e on ReactiveX:master.

@coveralls
Copy link

coveralls commented Apr 2, 2017

Coverage Status

Coverage decreased (-0.07%) to 97.612% when pulling a0b2f1a on MidnightWonderer:bug/too-strict-type-checking into 3e9d529 on ReactiveX:master.

Copy link
Member

@kwonoj kwonoj left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was originally thinking replicate existing test cases but using non-native promise (like bluebird), but this test looks ok to me. I'll leave this PR opened to get another approval, or feedback.

@kwonoj
Copy link
Member

kwonoj commented May 2, 2017

I guess this is for minor, labeled it for now.

@staltz
Copy link
Member

staltz commented May 5, 2017

PR LGTM

@benlesh benlesh merged commit ade1fd5 into ReactiveX:master May 9, 2017
@lock
Copy link

lock bot commented Jun 6, 2018

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.

@lock lock bot locked as resolved and limited conversation to collaborators Jun 6, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants