Potential
was written as an exercise in passing the full Promises/A+ spec. Emphasis is on adhering to the spec language and commenting the source code accordingly, so as to serve as an educational example. Extended methods such as catch
, all
, map
, and spread
are also included.
Potential
is neither performance-optimized nor designed for maximum safety in production use (e.g. providing type checks, antipattern warnings and similar). Instead, it concentrates on relatively straightforward source code written using recent language features. For a highly performant, feature-rich, robust promise library, check out Bluebird.
Potential
is available as an npm module for Node.js projects. You can add it to your project in the usual fashion:
npm install potential --save
Then you can require
it in your modules like so:
var Potential = require('potential');
Potential(executor)
Potential.defer()
deferral.resolve
deferral.reject
deferral.promise
Potential.resolve
/ Potential.reject
promise
This is the approach favored by ES6 and contemporary promise libraries. You typically only need to construct a promise from scratch if you are wrapping an async routine that does not already return promises. If you already have a promise, you can post-process it by return
ing or throw
ing from its handler.
var promise = new Potential(function(resolve, reject){
// call resolve(val) or reject(val) at some point
})
promise
will be resolved with val
if resolve(val)
is called, or rejected with val
if reject(val)
is called. Both the resolver and rejector are pre-bound to the promise.
Side note: when Potential
is used as a function, it always return
s a unique promise instance, whether called with new
or not. In fact, new
does not affect Potential
's return value at all. However, it is still recommended to write the new
operator if only to emphasize Potential
's role as a constructor and avoid confusing style inconsistencies.
A deferral is just a container grouping a promise with its associated resolver and rejector functions. The constructor pattern hides this conceptually irrelevant wrapper object and discourages improper leaking of the resolver/rejector to different scopes. However, there is nothing wrong with deferrals when used correctly.
var deferral = Potential.defer();
var promise = deferral.promise;
// call deferral.resolve(val) or deferral.reject(val) at some point
promise
will be resolved with val
if deferral.resolve(val)
is called, or rejected with val
if deferral.reject(val)
is called. Both resolve
and reject
methods are pre-bound to deferral
.
You can also create promises pre-resolved or pre-rejected with any val
. Note that val
can be a synchronous value or even a promise/thenable; nested thenables are recursively unwrapped. This is especially useful when you need to do any of the following:
Potential
-based promisevar resolvedPromise = Potential.resolve(val);
var rejectedPromise = Potential.reject(val);
There is an important distinction between the terms resolve and fulfill. A promise fulfilled with val
will invoke its success handlers with val
. The resolution procedure however merely attempts fulfillment, but can result in rejection under certain circumstances. Examine the table below for details.
Value provided | return of Potential.resolve |
return of Potential.reject |
---|---|---|
Synchronous value val (any JS value, including undefined , an Error instance, etc.) |
a promise fulfilled with val |
a promise rejected with val |
Promise/thenable that fulfills with val |
a promise that fulfills with val |
a promise that rejects with val |
Promise/thenable that rejects with val |
a promise that rejects with val |
a promise that rejects with val |
Promise chains allow for serial processing of asynchronous steps: first do A, then do B, and so on. However, another common need is to wait for multiple independent asynchronous actions to all complete, so that their results can be used together.
Take an iterable collection (or promise/thenable for iterable) of values — any of which may be normal values, promises, or thenables — and return a promise for an array of final results:
// foo, bar, baz may be any mix of normal values, promises, and/or thenables
Promise.all([fooPromise, barThenable, bazValue]);
.then(function (results) {
console.log('finalFoo', results[0]);
console.log('finalBar', results[1]);
console.log('finalBaz', results[2]);
})
Importantly, the original order of the collection is preserved in the final results, although the individual results may finish at any time. The handler function is only called once all results have completed. If any of the original promises rejects, the success handler is not called; instead, the returned promise from .all
is immediately rejected.
Promise instances have an equivalent all
method:
promiseForArray.all().then(arr => console.log(arr)) // 1, 2, 3
The .all
method is frequently used with .spread
.
Identical to .all
except values are passed through a provided mapper function.
// foo, bar, baz may be any mix of normal values, promises, and/or thenables
const mapper = val => val + '!';
const inputArr = [aPromise, bThenable, cValue];
Promise.map(inputArr, mapper);
.then(function (mappedResults) {
console.log(mappedResults); // a!, b!, c!
});
Promise instances have an equivalent map
method:
promiseForArray.map(val => val + '!').then(arr => console.log(arr)) // 1!, 2!, 3!
Take an iterable collection (or promise for collection) of input values, thenables, and/or promises. Return a promise for the first value to settle. If any promise rejects before then, reject the output promise.
Potential.race([fastPromiseForA, fasterPromiseForB, slowPromiseForC])
.then(console.log.bind(console)) // B
Promise instances have an equivalent race
method.
Create a promise which delays resolution until X ms.
Potential.delay('hello', 1000)
.then(console.log.bind(console)); // after one second: 'hello'
Promise instances have an equivalent delay
method:
promiseForHello.delay(1000).then(console.log.bind(console)) // after one second: 'hello'
A promise's main method is .then
, which takes two optional handler functions:
promise.then(successFn, failureFn);
If either parameter is not a function (e.g. null
) it is ignored. If promise
is fulfilled with val
, then successFn
will be invoked with val
. If promise
is rejected with val
, then failureFn
will be invoked with val
.
.then
returns a new promise whose fate is tied to the functions passed in (or not) to the previous .then
.
p1.then(successFn, failureFn) // returns p2 which we can chain `.then` on
.then(successF2, failureF2);
p1
fulfills or rejects with a value and does not have the appropriate handler (successFn
or failureFn
is not a function), p2
is fulfilled or rejected with the same value. This is called bubbling. In other words, values bubble down to the first handler of the correct type in the chain.p1
fulfills or rejects with a value v1
and has the appropriate handler (successFn
or failureFn
is a function), that handler is invoked with v1
.
x
, p2
is fulfilled with x
, meaning successF2
is invoked with x
.pX
, p2
assimilates that promise or thenable, meaning p2
will behave as if it were pX
— calling handlers based on the fulfillment or rejection of pX
.throw
s an error e
, p2
is rejected with e
, meaning failureF2
is invoked with e
.This complex behavior is the reason why promises are versatile, powerful, and expressive.
For convenience, an error handler can be inserted into a chain using catch
:
p1.then(successFn)
.catch(failureFn)
promise.catch(failureFn)
is just a wrapper for promise.then(null, failureFn)
and returns the same promise .then
would. However, note that the following are distinct:
// possibly problematic:
p1.then(successFn, failureFn) // failureFn won't catch errs thrown by successFn
// better:
p1.then(successFn)
.then(null, failureFn); // failureFn catches both p1 rejection & successFn errors
// same behavior as previous example, but cleaner to write:
p1.then(successFn)
.catch(failureFn); // failureFn catches both p1 rejection & successFn errors
Due to the above, it is generally good practice to add a catch
below success handlers rather than using parallel success-error handlers. Remember, because of value bubbling, an error handler can be set at the bottom of a chain:
p1.then(s1)
.then(s2)
.then(s3)
.catch(console.log.bind(console)); // will log errors from p1, s1, s2, or s3.
Sometimes you want to run a handler to perform a side effect (e.g. resource cleanup) regardless of whether a promise fulfilled or rejected. You may also want to continue the promise chain afterwards with the resulting fulfillment or rejection of your original promise. Finally, you may also want to delay continuation of the promise chain, for coordination purposes. finally
satisfies all these needs. It lets you register a handler which will be invoked with no arguments, allowing values and rejections to pass through, but waiting on the handler before doing so:
promiseA
.finally(() => {
promiseB = db.close();
return promiseB;
})
.then(handlePromiseAResult, handlePromiseAErr) // delayed until promiseB completes, but ignores value/state of promiseB
If you have a promise for an array of values, calling .then(function success (arr) {...})
will invoke success
with a single arr
of results. If you know ahead of time what each index of the array is supposed to contain, this can lead to code like the following:
promiseForArray
.then(function (results) {
var rawData = results[0];
var metaData = results[1];
var flag = results[2];
console.log(rawData, metaData, flag);
})
If you prefer to use formal parameters rather than an array of indexed results, .spread
takes a handler function just like .then
, but "spreads" the eventual results over the handler's parameters:
promiseForArray
.spread(function (rawData, metaData, flag) {
console.log(rawData, metaData, flag);
})
Note that .spread
returns a promise just like .then
, and its handler behaves just like a .then
success handler with respect to return values / thrown errors and promise chaining. Importantly, .spread
does not take an optional error handler; any additional function arguments to .spread
are ignored.
Finally, note that .spread
implicitly calls .all
on the values array, so every formal parameter will be a resolved value, not a promise.