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

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).