Return already resolved promise

Question

I have an existing project that has a lot of asynchronous functions that return promises. I\'m adding some caching so that in some cases the asynchronous functions will complet

Answer 1

@Eselk,

In my experience, the $.Deferred(function(def) {...}); construction is rarely needed, though I guess it can be quite useful in some circumstances.

Firstly, :

return $.Deferred(function(def) { def.resolve(); }).promise();

will simplify to :

return $.Deferred().resolve().promise();

Secondly, in DataService.makeRequest() you can avoid the need for an explicit $.Deferred by exploiting .then(), as follows :

function DataService() {
    var self = this;
    self.makeRequest = function (functionName, data) {
        return $.ajax({
            type: "POST",
            url: "WebService.asmx/" + functionName,
            data: JSON.stringify(data),
            contentType: "application/json; charset=utf-8",
            dataType: "json"
        }).then(null, function (xhr, status, error) {
            var ex;
            try {
                ex = eval("(" + xhr.responseText + ")");
                ex.message = ex.Message;
                ex.Message = undefined;
            } catch (ex2) {
                ex = {
                    message: "Invalid Response From Server:\r\n" + xhr.responseText
                };
            }
            if (ex.message == "LoginRequired") {
                app.viewModels.main.loginRequired(true);
            } else {
                app.showError(ex.message);
            }

            return ex.message;
        });
    };
}

The key aspects here are :

• $.ajax() returns a promise-compatible jqXHR object, which (on success/error) is immediately acted upon and modified by .then().
• .then(null, ...) - causes a new promise to be passed on, resolved with the same values as the original promise returned by $.ajax(). Thus, under the 'done' (ie ajax success) condition, .then() is completely transparent.
• return ex.message; - causes a new promise to be passed on, rejected with ex.message.

The nett effect should be identical to your original code though, IMHO, chaining .then() is significantly cleaner than setting everything up inside a $.Deferred() callback.

By the way, you may be able to avoid the need for eval("(" + xhr.responseText + ")") etc by setting an appropriate HTTP header server-side such that your '.Message' appears directly as the status argument (or xhr.status?) of the fail callback. For example, in PHP you would do something like :

$message = "my custom message";
header("HTTP/1.1 421 $message");
exit(0);

I'm sure ASP offers the same capability.

IIRC, any 4xx series status code will do the job. 421 just happens to be one without a specific meaning.