Deferred pattern is one of the most commonly used design patterns in JavaScript world and in programming in general. It postpones the action to a later stage for whatever reason, but mostly because the expected value is not available yet.
Promise falls nicely to this category. It boxes the future value and provides a way to unbox it whether it realizes (then) or fails (catch). The basic usage reveals how the Promise pattern does work:
const promise = new Promise(function(resolve, reject) {
asyncCall(function(err, result) {
if (err) {
reject(err);
} else {
resolve(result);
}
})
})
promise.then(successHandler).catch(rejectHandler)
New Promise object is constructed and the resolver function is called some time in the constructor. From inside resolver function the asynchronous call is triggered and once the result comes back the status of the Promise changes from pending to settled by calling reject
or resolved
. At that point any callback provided by calling .than()
pipe is executed in the same order how they were registered.
From the above is evident that the programmer or user has limited control when the promise settlement start to happen. Calling the constructor makes the things moving right away. Of course unless we inject some handlers from calling scope or we close over the provided resolve
and reject
levers.
const makeDeferred = () => {
const deferred = {};
deferred.promise = new Promise((resolve, reject) => {
deferred.resolve = resolve;
deferred.reject = reject;
});
return deferred;
}
The new object contains promise
and the handlers to reject
or resolve
it.
{ promise, resolve, reject }
And that's it. In the simple form and shape.
Deferred as subclass of Promise
The disadvantage if this approach is hacky implementation. The Promise object needs to be thenable and as per specification it needs to return the Promise object instantiated from the same class as the calling object. This means internally the constructor is called with standard resolver method which we need to support. Hence the check for the resolver argument. Also it is going against type definition where Promise
expects resolver function in the constructor. Secondly we are robbing ourselves from any potential native performance optimization regarding Promise
class or it's instance.
class DeferredPromise extends Promise {
constructor(resolver) {
const that = {};
super(function(resolve, reject) {
Object.assign(that, {resolve, reject})
});
Object.assign(this, that)
if (resolver) {
resolver(this.resolve, this.reject)
}
}
}
var deferred = new DeferredPromise();
deferred.then(doStuffWithValue)
deferred.resolve('Hello World')
Although this is not recommended, it might be sometimes useful if you have existing middle-ware pipeline working with promise objects and you can get away with dodgy typing.
Deferred as result of a factory function
Building on the original principle, much cleaner and recommended approach is to user factory method
export function Defer(workload) {
let _reject, _resolve;
const _p = new Promise(function (resolve, reject) {
_resolve = resolve;
_reject = reject;
})
const trigger = (function (workload) {
let _result = undefined;
return function() {
if (_result) {
return _result;
}
return _result = workload()
.then(data => {
_resolve(data)
})
.catch(reason => {
_reject(reason)
})
}
})(workload)
return {
get promise() { return _p },
trigger,
}
}
var deferred = Defer(() => http.get(url))
// in some class or API expecting Promise value
deferred.promise.then(doStuffWithValue)
// some later stage in app
deferred.trigger()
This implementation takes the async function returning a Promise and returns the new Promise object wrapping the future promise object returned from the async function and the handler to allow as to trigger the async function in the future.
We can see that the _reject
and _resolve
variables are closed over and the resolve
resp reject
handlers from the Promise implementation are assigned.
trigger
method implements simple caching in case it gets called multiple times.
Wrap up
If anybody find this useful I wrapped all of the above in the platform agnostic npm package
, which can be installed by
$ npm install deferable
Or it can be found on github/webduvet/deferable.git. It offers both the Class flavor as well as the Factory flavor.
Deferred Promise pattern has many use cases e.g. api call throttling, user input de-bounce, user action timeout etc.
In this the next article I elaborate one particular use case of Deferred Promise pattern - throttling the async calls.
Top comments (0)