Domenica Denicola wrote:
> Since there's no real advantage to the `PromiseResolver` approach, and there
> are a number of disadvantages, we were hoping to switch to the prevalent
> `(resolve, reject)` signature in the revised DOM promises spec.
>
> Let us know what you think!
One advantage to the `PromiseResolver` is that it's easier to pass around than
two separate functions. Passing the resolver around isn't common, but at my
workplace we've made use of it in a "requester" pattern.
function Requester() {
this.requests = Object.create();
}
Requester.prototype = {
respond: function(requestName, callback) {
this.requests[requestName] = callback;
},
request: function(requestName, ...values) {
return new Promise(resolver => {
this.requests[requestName](resolver, ...values);
});
}
};
This allows a general data retrieval mechanism to easily be dropped in place.
For instance, if you are writing a Grid class which should display tabular data
and it needs to request new data any time the page is changed or columns or
sorted, you can make it a requester. Then whoever creates a Grid can define
how it gets its data:
var grid = new Grid();
grid.respond('load-data', function(resolver, page, sorts) {
var request_params = {
// ...
page: page,
sorts: sorts,
// ...
};
makeAjaxCall(request_params).then(data => {
resolver.resolve(data);
});
});
Whenever the grid wants to load data, it will internally make a "load-data"
request.
All of these things could be written to use `resolve` and `reject` functions
rather than a `PromiseResolver` object, but having one thing to pass around has
been nice in my experience (we call that thing the "Obligation" because if you
get it it's your obligation to fulfill the promise).
Nathan
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
