202

I want to use (native) promises in my frontend app to perform XHR request but without all the tomfoolery of a massive framework.

I want my xhr to return a promise but this doesn't work (giving me: Uncaught TypeError: Promise resolver undefined is not a function)

function makeXHRRequest (method, url, done) {
  var xhr = new XMLHttpRequest();
  xhr.open(method, url);
  xhr.onload = function() { return new Promise().resolve(); };
  xhr.onerror = function() { return new Promise().reject(); };
  xhr.send();
}

makeXHRRequest('GET', 'http://example.com')
.then(function (datums) {
  console.log(datums);
});
Florian Margaine
  • 50,873
  • 14
  • 87
  • 110
SomeKittens
  • 35,809
  • 19
  • 104
  • 135

6 Answers6

411

I'm assuming you know how to make a native XHR request (you can brush up here and here)

Since any browser that supports native promises will also support xhr.onload, we can skip all the onReadyStateChange tomfoolery. Let's take a step back and start with a basic XHR request function using callbacks:

function makeRequest (method, url, done) {
  var xhr = new XMLHttpRequest();
  xhr.open(method, url);
  xhr.onload = function () {
    done(null, xhr.response);
  };
  xhr.onerror = function () {
    done(xhr.response);
  };
  xhr.send();
}

// And we'd call it as such:

makeRequest('GET', 'http://example.com', function (err, datums) {
  if (err) { throw err; }
  console.log(datums);
});

Hurrah! This doesn't involve anything terribly complicated (like custom headers or POST data) but is enough to get us moving forwards.

The promise constructor

We can construct a promise like so:

new Promise(function (resolve, reject) {
  // Do some Async stuff
  // call resolve if it succeeded
  // reject if it failed
});

The promise constructor takes a function that will be passed two arguments (let's call them resolve and reject). You can think of these as callbacks, one for success and one for failure. Examples are awesome, let's update makeRequest with this constructor:

function makeRequest (method, url) {
  return new Promise(function (resolve, reject) {
    var xhr = new XMLHttpRequest();
    xhr.open(method, url);
    xhr.onload = function () {
      if (this.status >= 200 && this.status < 300) {
        resolve(xhr.response);
      } else {
        reject({
          status: this.status,
          statusText: xhr.statusText
        });
      }
    };
    xhr.onerror = function () {
      reject({
        status: this.status,
        statusText: xhr.statusText
      });
    };
    xhr.send();
  });
}

// Example:

makeRequest('GET', 'http://example.com')
.then(function (datums) {
  console.log(datums);
})
.catch(function (err) {
  console.error('Augh, there was an error!', err.statusText);
});

Now we can tap into the power of promises, chaining multiple XHR calls (and the .catch will trigger for an error on either call):

makeRequest('GET', 'http://example.com')
.then(function (datums) {
  return makeRequest('GET', datums.url);
})
.then(function (moreDatums) {
  console.log(moreDatums);
})
.catch(function (err) {
  console.error('Augh, there was an error!', err.statusText);
});

We can improve this still further, adding both POST/PUT params and custom headers. Let's use an options object instead of multiple arguments, with the signature:

{
  method: String,
  url: String,
  params: String | Object,
  headers: Object
}

makeRequest now looks something like this:

function makeRequest (opts) {
  return new Promise(function (resolve, reject) {
    var xhr = new XMLHttpRequest();
    xhr.open(opts.method, opts.url);
    xhr.onload = function () {
      if (this.status >= 200 && this.status < 300) {
        resolve(xhr.response);
      } else {
        reject({
          status: this.status,
          statusText: xhr.statusText
        });
      }
    };
    xhr.onerror = function () {
      reject({
        status: this.status,
        statusText: xhr.statusText
      });
    };
    if (opts.headers) {
      Object.keys(opts.headers).forEach(function (key) {
        xhr.setRequestHeader(key, opts.headers[key]);
      });
    }
    var params = opts.params;
    // We'll need to stringify if we've been given an object
    // If we have a string, this is skipped.
    if (params && typeof params === 'object') {
      params = Object.keys(params).map(function (key) {
        return encodeURIComponent(key) + '=' + encodeURIComponent(params[key]);
      }).join('&');
    }
    xhr.send(params);
  });
}

// Headers and params are optional
makeRequest({
  method: 'GET',
  url: 'http://example.com'
})
.then(function (datums) {
  return makeRequest({
    method: 'POST',
    url: datums.url,
    params: {
      score: 9001
    },
    headers: {
      'X-Subliminal-Message': 'Upvote-this-answer'
    }
  });
})
.catch(function (err) {
  console.error('Augh, there was an error!', err.statusText);
});

A more comprehensive approach can be found at MDN.

Alternatively, you could use the fetch API (polyfill).

Community
  • 1
  • 1
SomeKittens
  • 35,809
  • 19
  • 104
  • 135
  • 3
    You might also want to add options for `responseType`, authentication, credentials, `timeout`… And `params` objects should support blobs/bufferviews and `FormData` instances – Bergi May 03 '15 at 12:13
  • 4
    Would it be better to return a new Error on reject? – prasanthv May 14 '15 at 16:53
  • 1
    Additionally, it does not make sense to return `xhr.status` and `xhr.statusText` on error, since they are empty in that case. – dqd Oct 01 '15 at 07:59
  • @prasanthv it wouldn't just be better - as @dqd pointed out, `xhr.status` and `xhr.statusText` will contain nothing, since there was no (valid) response, so the code sample (as-is) doesn't make sense in this regard; likely, the most meaningful thing we can do, is something like `reject(new Error("unable to complete " + opts.method + " request for: " + opts.url))` – mindplay.dk Jul 20 '16 at 16:02
  • 2
    This code seems to work as advertised, except for one thing. I expected that the right way to pass params along to a GET request was via xhr.send(params). However, GET requests ignore any values sent to the send() method. Instead, they just need to be query string params on the URL itself. So, for the above method, if you want the "params" argument to be applied to a GET request, the routine needs to be modified to recognize a GET vs. POST, and then conditionally append those values to the URL that's handed to xhr.open(). – hairbo Oct 11 '16 at 21:24
  • Will this code work with sync calls? Will this create a xhr sync promise? – ayxos Mar 31 '17 at 04:41
  • 1
    One should use `resolve(xhr.response | xhr.responseText);` In most browsers the repsonse is in responseText in the meantime. – heinob Mar 21 '19 at 13:39
  • this works like a charm! Yet behaviour of cookie handling seems to be different: If wrapped inside the Promise, an Auth Cookie returned from an API is not saved. If I leave everything the same but remove the Promise wrapping, the cookie is written. Any ideas about why that is the case and if I can get around that behaviour? – gauguerilla Mar 21 '20 at 20:01
57

This could be as simple as the following code.

Keep in mind that this code will only fire the reject callback when onerror is called (network errors only) and not when the HTTP status code signifies an error. This will also exclude all other exceptions. Handling those should be up to you, IMO.

Additionally, it is recommended to call the reject callback with an instance of Error and not the event itself, but for sake of simplicity, I left as is.

function request(method, url) {
    return new Promise(function (resolve, reject) {
        var xhr = new XMLHttpRequest();
        xhr.open(method, url);
        xhr.onload = resolve;
        xhr.onerror = reject;
        xhr.send();
    });
}

And invoking it could be this:

request('GET', 'http://google.com')
    .then(function (e) {
        console.log(e.target.response);
    }, function (e) {
        // handle errors
    });
Peleg
  • 1,124
  • 9
  • 7
15

For anyone who searches for this now, you can use the fetch function. It has some pretty good support.

fetch('http://example.com/movies.json')
  .then(response => response.json())
  .then(data => console.log(data));

I've firstly used @SomeKittens's answer, but then discovered fetch that does it for me out of the box :)

microo8
  • 2,910
  • 4
  • 32
  • 58
  • 2
    Older browsers don’t support the `fetch` function, but [GitHub has published a polyfill](https://github.com/github/fetch). – bdesham Sep 06 '17 at 21:22
  • 2
    I wouldn't recommend `fetch` as it doesn't support cancellation yet. – James Dunne Nov 05 '17 at 03:14
  • 2
    The spec for the Fetch API now provides for cancellation. Support has so far shipped in Firefox 57 https://bugzilla.mozilla.org/show_bug.cgi?id=1378342 and Edge 16. Demos: https://fetch-abort-demo-edge.glitch.me/ & https://mdn.github.io/dom-examples/abort-api/. And there are open Chrome & Webkit feature bugs https://bugs.chromium.org/p/chromium/issues/detail?id=750599 & https://bugs.webkit.org/show_bug.cgi?id=174980. How-to: https://developers.google.com/web/updates/2017/09/abortable-fetch & https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal#Examples – sideshowbarker Nov 23 '17 at 01:17
  • The answer at https://stackoverflow.com/questions/31061838/how-do-i-cancel-an-http-fetch-request/47250621#47250621 has cancelable-fetch code example that so far already works in Firefox 57+ and Edge 16+ – sideshowbarker Nov 23 '17 at 01:18
  • Cancelable fetch is still giving me trouble in Chrome 69. Using XMLHttpRequest just seems a whole lot easier. – Matt Montag Sep 29 '18 at 09:21
  • 1
    @microo8 It would be nice to have a simple example using fetch, and here seems liek a good place to put it. – jpaugh Jul 06 '20 at 23:57
9

I think we can make the top answer much more flexible and reusable by not having it create the XMLHttpRequest object. The only benefit of doing so is that we don't have to write 2 or 3 lines of code ourselves to do it, and it has the enormous drawback of taking away our access to many of the API's features, like setting headers. It also hides properties of the original object from the code that's supposed to handle the response (for both successes and errors). So we can make a more flexible, more widely applicable function by just accepting the XMLHttpRequest object as input and passing it as the result.

This function converts an arbitrary XMLHttpRequest object into a promise, treating non-200 status codes as an error by default:

function promiseResponse(xhr, failNon2xx = true) {
    return new Promise(function (resolve, reject) {
        // Note that when we call reject, we pass an object
        // with the request as a property. This makes it easy for
        // catch blocks to distinguish errors arising here
        // from errors arising elsewhere. Suggestions on a 
        // cleaner way to allow that are welcome.
        xhr.onload = function () {
            if (failNon2xx && (xhr.status < 200 || xhr.status >= 300)) {
                reject({request: xhr});
            } else {
                resolve(xhr);
            }
        };
        xhr.onerror = function () {
            reject({request: xhr});
        };
        xhr.send();
    });
}

This function fits very naturally into a chain of Promises, without sacrificing the flexibility of the XMLHttpRequest API:

Promise.resolve()
.then(function() {
    // We make this a separate function to avoid
    // polluting the calling scope.
    var xhr = new XMLHttpRequest();
    xhr.open('GET', 'https://stackoverflow.com/');
    return xhr;
})
.then(promiseResponse)
.then(function(request) {
    console.log('Success');
    console.log(request.status + ' ' + request.statusText);
});

catch was omitted above to keep the sample code simpler. You should always have one, and of course we can:

Promise.resolve()
.then(function() {
    var xhr = new XMLHttpRequest();
    xhr.open('GET', 'https://stackoverflow.com/doesnotexist');
    return xhr;
})
.then(promiseResponse)
.catch(function(err) {
    console.log('Error');
    if (err.hasOwnProperty('request')) {
        console.error(err.request.status + ' ' + err.request.statusText);
    }
    else {
        console.error(err);
    }
});

And disabling the HTTP status code handling doesn't require much change in the code:

Promise.resolve()
.then(function() {
    var xhr = new XMLHttpRequest();
    xhr.open('GET', 'https://stackoverflow.com/doesnotexist');
    return xhr;
})
.then(function(xhr) { return promiseResponse(xhr, false); })
.then(function(request) {
    console.log('Done');
    console.log(request.status + ' ' + request.statusText);
});

Our calling code is longer, but conceptually, it's still simple to understand what's going on. And we don't have to rebuild the entire web request API just to support its features.

We can add a few convenience functions to tidy up our code, as well:

function makeSimpleGet(url) {
    var xhr = new XMLHttpRequest();
    xhr.open('GET', url);
    return xhr;
}

function promiseResponseAnyCode(xhr) {
    return promiseResponse(xhr, false);
}

Then our code becomes:

Promise.resolve(makeSimpleGet('https://stackoverflow.com/doesnotexist'))
.then(promiseResponseAnyCode)
.then(function(request) {
    console.log('Done');
    console.log(request.status + ' ' + request.statusText);
});
jpmc26
  • 23,237
  • 9
  • 76
  • 129
5

jpmc26's answer is quite close to perfect in my opinion. It has some drawbacks, though:

  1. It exposes the xhr request only until the last moment. This does not allow POST-requests to set the request body.
  2. It is harder to read as the crucial send-call is hidden inside a function.
  3. It introduces quite a bit of boilerplate when actually making the request.

Monkey patching the xhr-object tackles these issues:

function promisify(xhr, failNon2xx=true) {
    const oldSend = xhr.send;
    xhr.send = function() {
        const xhrArguments = arguments;
        return new Promise(function (resolve, reject) {
            // Note that when we call reject, we pass an object
            // with the request as a property. This makes it easy for
            // catch blocks to distinguish errors arising here
            // from errors arising elsewhere. Suggestions on a 
            // cleaner way to allow that are welcome.
            xhr.onload = function () {
                if (failNon2xx && (xhr.status < 200 || xhr.status >= 300)) {
                    reject({request: xhr});
                } else {
                    resolve(xhr);
                }
            };
            xhr.onerror = function () {
                reject({request: xhr});
            };
            oldSend.apply(xhr, xhrArguments);
        });
    }
}

Now the usage is as simple as:

let xhr = new XMLHttpRequest()
promisify(xhr);
xhr.open('POST', 'url')
xhr.setRequestHeader('Some-Header', 'Some-Value')

xhr.send(resource).
    then(() => alert('All done.'),
         () => alert('An error occured.'));

Of course, this introduces a different drawback: Monkey-patching does hurt performance. However this should not be a problem assuming that the user is waiting mainly for the result of the xhr, that the request itself takes orders of magnitude longer than setting up the call and xhr requests not being sent frequently.

PS: And of course if targeting modern browsers, use fetch!

PPS: It has been pointed out in the comments that this method changes the standard API which can be confusing. For better clarity one could patch a different method onto the xhr object sendAndGetPromise().

t.animal
  • 1,885
  • 1
  • 15
  • 21
  • I avoid monkey patching because it's surprising. Most developers expect that standard API function names invoke the standard API function. This code still hides the actual `send` call but also can confuse readers who know that `send` has no return value. Using more explicit calls makes it clearer that additional logic has been invoked. My answer does need to be adjusted to handle arguments to `send`; however, it's probably better to use `fetch` now. – jpmc26 Apr 14 '19 at 02:09
  • I guess it depends. If you return/expose the xhr request (which seems dubious anyhow) you are absolutely right. However I don't see why one would not do this within a module and expose only the resulting promises. – t.animal Apr 14 '19 at 09:50
  • I'm referring specially to anyone having to maintain the code you do it in. – jpmc26 Apr 14 '19 at 22:26
  • Like I said: It depends. If your module is so huge that the promisify function gets lost between the rest of the code you've probably got other problems. If you've got a module where you just want to call some endpoints and return promises I don't see a problem. – t.animal Apr 17 '19 at 09:38
  • I disagree that it depends on the size of your code base. It's confusing to see a standard API function do something other than it's standard behavior. – jpmc26 Apr 17 '19 at 11:28
1

If you want your code to work in old browsers, put this in the <head> of your HTML document:

<script>
self.Promise||document.write("<script src=/path/to/promise/polyfill.js><\/script>");
</script>

Replace /path/to/promise/polyfill.js with the path to your Promise polyfill. This will create a Promise class if the class is not already native and allow your code to run on old browsers such as Internet Explorer. Internet Explorer and other old browsers make up a small minority of the market share which might seem insignificant, but this still translates to millions of users so I do not recommend totally dismissing these users.

May I suggest this Promise polyfill:

https://github.com/stefanpenner/es6-promise/

Now you have access to the Promise class.

If you want your code to work in really old browsers like IE 6-8 you need to use onreadystatechange instead of onload. There is no harm in this as onreadystatechange remains in use in all current browsers for backwards compatibility:

function send_request(xhr, data, timeout) {
    return new Promise(function (resolve, reject) {
        var s, p, i;
        if (data && data.constructor==Object) {// serialize object
            s = "_="+(new Date).getTime();
            for (p in data) if (data.hasOwnProperty(p)) {
                if (!data[p] || data[p].constructor!=Array) {
                    data[p] = [data[p]]
                }
                for (i=0; i<data[p].length; i++) {
                    s+= "&"+encodeuricomponent(p)+"="+encodeuricomponent(data[p][i]);
                }
            }
            data = s;
        }
        xhr.onreadystatechange = function() {
            if (xhr.readyState==4) {
                resolve(xhr);
            }
        }
        xhr.send(data);
        if (timeout) {
            settimeout(function() {
                reject("timeout");
                xhr.abort();
            }, timeout);// milliseconds until timeout
        }
    });
}

xhr = new XMLHttpRequest();
xhr.open("GET", "/some/file", true);
send_request(xhr).then(function(xhr) {
    if (xhr.status>=200 || xhr.status<400) {
        //success
        alert(xhr.responseText);
    }
    else {
        return Promise.reject(xhr.statusText? xhr.status+" "+xhr.statusText: "error");
    }
})

Keep in mind that IE 6 does not support XMLHttpRequest so you would need to polyfill that as well which you can do with ActiveX. Something like the following in your document <head> might work:

<!--[if lt IE 7]>
<script>
// This is just an example. Use at your own risk.
function XMLHttpRequest() {
    try {
        return new ActiveXObject("Msxml2.XMLHTTP.6.0")
    }
    catch (e) {
        return new ActiveXObject("Msxml2.XMLHTTP.3.0")
    }
}
</script>
<![endif]-->
PHP Guru
  • 964
  • 4
  • 15