I use the Q library that supports the Promise specification well. But I also try to use the Promise class that has been implemented in Chrome not long ago (experimentally).
There's the defer function in Q that can be used for creating a non-fulfilled promise that can be resolved or rejected in the future.
I've implemented the same functionality using the native Promise presented in Chrome. Here's an example:
var defer = function() {
var result = {};
result.promise = new Promise(function(resolve, reject) {
result.resolve = function(value) {
resolve(value);
};
result.reject = function(value) {
reject(value);
};
});
return result;
};
var deferred = defer();
deferred.promise.then(function(value) {
alert(value);
});
deferred.resolve(10);
I'm curious is there any design flaw in this solution such as performance slowdown or incorrectness.
You are creating unnecessary function objects.
You can just do:
var defer = function() {
var result = {};
result.promise = new Promise(function(resolve, reject) {
result.resolve = resolve;
result.reject = reject;
});
return result;
};
Design flaw is doing this in the first place, native promises are useless if you are using Q.
See http://bluebirdjs.com/docs/benchmarks.html for benchmarks. There are some JSPerf benchmarks as well, however "for a reasonably fast promise implementations latency is going to be fully determined by the scheduler being used and is therefore not interesting to benchmark. JSPerfs that benchmark promises tend to benchmark latency."
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With