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 --saveThen you can require it in your modules like so:
var Potential = require('potential');Potential(executor)Potential.defer()deferral.resolvedeferral.rejectdeferral.promise
Potential.resolve/Potential.reject- Dual methods (static and instance)
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 returning or throwing 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 returns 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 pointpromise 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:
- create a fresh starting point for a dynamically-built promise chain
- convert a known third-party thenable into a
Potential-based promise - normalize an unknown value (synchronous or a promise/thenable) into a promise
var 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, 3The .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)) // BPromise 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);- If
p1fulfills or rejects with a value and does not have the appropriate handler (successFnorfailureFnis not a function),p2is 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. - If
p1fulfills or rejects with a valuev1and has the appropriate handler (successFnorfailureFnis a function), that handler is invoked withv1.- if the handler returns a normal value
x,p2is fulfilled withx, meaningsuccessF2is invoked withx. - if the handler returns a promise or thenable
pX,p2assimilates that promise or thenable, meaningp2will behave as if it werepX— calling handlers based on the fulfillment or rejection ofpX. - if the handler
throws an errore,p2is rejected withe, meaningfailureF2is invoked withe.
- if the handler returns a normal value
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 errorsDue 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 promiseBIf 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.