5 ms·
If you're looking for a more lightweight solution than Bluebird (because, say, you're writing client side code - Bluebird is a bit heavy weight): * [promise-to
by jwalton 11y ago
If you're looking for a more lightweight solution than Bluebird (because, say, you're writing client side code - Bluebird is a bit heavy weight):
* [promise-tools](https://github.com/benbria/node-promise-tools https://github.com/benbria/node-promise-tools) is a library with a lot of the cool flow control from Bluebird, but is tiny and works with native Promises.
* [promise-breaker](https://github.com/jwalton/node-promise-breaker https://github.com/jwalton/node-promise-breaker) is a library I wrote which is intended to make it really easy for third party libraries to support both promises and callbacks with a minimum of fuss (we also use this extensively internally as we convert our giant code base from callbacks to promises.) `callFn` and `applyFn` are also very handy for calling into existing callback based libraries from within promise based libraries.
- vkjv 11y agoVery neat! If you are interested in high level promises without any dependencies, like these, I have a small library inspired by some of the more useful helpers in Bluebird: [extends-promise](https://github.com/kjvalencik/extends-promise https://github.com/kjvalencik/extends-promise) Fair warning, it has an emphasis on simplicity of code rather than speed. It does a few things that are very likely inefficient. I wrote it primarily to scratch an itch I had--embedding in one-off node.js scripts without any dependencies.
- untog 11y agoAh, this was exactly what I was going to ask, thanks! Promise tools looks great - do you know of any equivalents of promisify and promisifyAll? I use them a lot with native libraries. EDIT: to answer my own question, this looks like it'll do it: https://github.com/pgaubatz/node-es6-promisify-all https://github.com/pgaubatz/node-es6-promisify-all but it doesn't seem to be actively maintained.
- mofle 11y agoCheck out https://github.com/sindresorhus/pify https://github.com/sindresorhus/pify
- amelius 11y agoI'm looking for an approach where promises can be canceled. For example, when I'm waiting for a promise p to be fulfilled, I might suddenly decide that I'm not interested anymore in the promise. So I could call (for example) p.cancel(), and the effect would be that the underlying code is stopped (and recursively everything it depends on).
- iheartmemcache 11y agoMicrosoft's RxJS does all that (and more): https://xgrommx.github.io/rx-book/content/getting_started_with_rxjs/creating_and_querying_observable_sequences/creating_and_subscribing_to_simple_observable_sequences.html https://xgrommx.github.io/rx-book/content/getting_started_wi... See this specific blog post for more details (though the Rx Book is fantastic): "That said, a sore point for Promises has always been their lack of cancelability. This leads to some interesting design patterns where you have to "protect" your promise callbacks from context-dependent changes. Because of this hoop-jumping, the most attractive RxJS feature that I've seen so far is the simple ability to cancel (aka, unsubscribe, aka, dispose) an RxJS stream before it completes." http://www.bennadel.com/blog/3030-canceling-rxjs-observables-with-ngondestroy-in-angular-2-beta-6.htm http://www.bennadel.com/blog/3030-canceling-rxjs-observables... (Though there are RxJS interops with more than just Angular)
- inglor 11y agoPromises, and in particular bluebird promises, are cancellable.
- iheartmemcache 11y agoECMAscript 6 has cancellable promises? This guy[1] seems to claim otherwise. I spent 20 minutes on skimming the spec[2] and from what I can tell, there's no language feature that has that `promiseCapability'[3] and those stackoverflow workarounds remain the only native ECMAscript way to do it. (I had to look up what that bluebird was and it looks like they both are libraries that offer cancellable functionality that the callee can invoke. So it looks like one is left to libraries regardless of Bluebird or RxJS or another solution. I'd opt for RxJS personally as RxJS is fairly first-class in the MS ecosystem (maybe one half-step beneath F#), and a lot of the product is based off of the RX research done by de Smet, Meijers, Beckman, et al (they've thrown prime engineering talent at it for years working out the concurrency semantics). But again, not in the JS ecosystem and just skimmed the standard[4] revision so there's a very high chance of me being wrong. I try to limit my comments to topics on which I'm relatively well-informed in general; in this case, please do regard my comments as poorly-informed-at-best.) [1] http://stackoverflow.com/a/30235261 http://stackoverflow.com/a/30235261 [2] https://tc39.github.io/ecma262/ https://tc39.github.io/ecma262/ [3] https://tc39.github.io/ecma262/#sec-promise-executor https://tc39.github.io/ecma262/#sec-promise-executor [4] Oh god, 25.4.4.1.1 - Runtime Semantics: PerformPromiseAll( iteratorRecord, constructor, resultCapability ). And I thought 'Rails magic' was bad. Step 6 goes all the way down from [a..r] haha.