Allow ES6 native Promises and other promise implementations about request-promise HOT 22 CLOSED

+1 for native

from request-promise.

While Bluebird is still faster than native promises they lack the features we've added to core for global error handling in promises. If people still want Bluebird on the frontend they'll get them injected by their compile toolchain.

from request-promise.

Hi @mikeal good point regarding the compile toolchain. I assume from that that native promises - and not Bluebird - lack the features? (Sorry, the grammar of your first sentence confuses me non-native speaker.;)

Which features in core are you actually referring to?

from request-promise.

Here's the first one https://iojs.org/api/process.html#process_event_unhandledrejection and there may be another one eventually for a totally unhandled promise. These are only features in native promises as these require low level vm hooks.

from request-promise.

Thanks for the pointer! Also offering native promise support seems unquestionable to me now.

from request-promise.

+1 for native, so long as we can override with our own version of Bluebird/whatever.

The native-or-bluebird module would also be an attractive option (instead of any-promise) and would align more with the history of this project.

request-promise is on bluebird 2, where bluebird 3 is now out so I am in favor of decoupling in order to make selecting the promise implementation more flexible.

from request-promise.

Thanks for the pointer to native-or-bluebird @MarkHerhold ! Indeed, the next version will at least support native and Bluebird.

from request-promise.

+1 for using native-or-bluebird, but many developers will probably want to choose which one specifically.

from request-promise.

+1 for native, as I would have pulled this into our project immediately if it supported native Promises.

from request-promise.

native-or-bluebird works for me. Note to @mikeal 's point about unhandledRejection, that seems to work on bluebird 3.1.1, not sure when it was added:

var bb = require('bluebird');
process.on('unhandledRejection', e => console.log('unhandled', e));
new bb.Promise((res,rej) => rej('foo'));

Output:

unhandled foo

from request-promise.

+1 for native support, along with the caveats above about letting people choose which Promise implementation they wish to use.

from request-promise.

any-promise
It supports es6-promise, bluebird, rsvp, when, q.

from request-promise.

👍 for having native promises supported.

from request-promise.

@jonathanong kindly informed us that they deprecated native-or-bluebird in favor of any-promise. So I checked out any-promise yesterday and @kevinbeaty even did a little update.

IMHO any-promise would be perfect for request-promise. Any thoughts?

from request-promise.

any-promise is fine. Go for it.

from request-promise.

Hey I'm wondering if there has been any progress on this?

We have an issue where bluebird promises are not playing nicely with our JS Clock override (zurvan) so we can't deterministically know when there are no more bluebird promises being processed by the event loop.

It would be great if users could choose which promise library they wanted to use (i.e. bluebird / es6 / etc)

For an idea you might want to look at durandaljs which allows users to override promises by overriding the default implementation of a function called system.deferred:
https://github.com/BlueSpire/Durandal/blob/master/src/durandal/js/system.js#L232

It would be cool if we could do something like require('request-promise').deferred = function .... or something like that to override the type of promise it uses.

Thanks!

from request-promise.

Hi @massimocode the idea is to use any-promise. Then you can use any promise implementation. Which one would solve your problem?

from request-promise.

I started to use native promises and the new ES6 fetch() HTTP method here https://github.com/glazedio/frisbee.

from request-promise.

what is status of this issue?

from request-promise.

Half done. There will be request-promise-native and request-promise-any.

Since I already implemented request-promise-native I can already say that it will be nearly identical to request-promise except the Bluebird specific parts of course (.finally(...) and continuation-local-storage support). If you plan to use native promises in all your environments this library is the right choice. You may use request-promise right now and later just replace it with request-promise-native without any other changes needed.

If you want to inject different promise implementations depending on the environment you'll have to wait for request-promise-any for which I can't yet say how the usage will look like.

from request-promise.

OK. Thank you for confirmation

from request-promise.

Hey buddies, I just released [email protected] and along with it request-promise-native and request-promise-any.

All three libraries share the same core and will be maintained in parallel. The migration is straight forward so feel free to choose the Promise implementation you like best.

Thanks everyone for contributing to this discussion. Cheers!

from request-promise.