Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Show HN: Xr – A modern ES6 Promise-based XMLHttpRequest wrapper (github.com/radiosilence)
32 points by antihero on March 2, 2015 | hide | past | favorite | 22 comments



You should look at `fetch` which is the new specification for a promise based XHR wrapper.

Polyfill: https://github.com/github/fetch

To use Fetch in Firefox (38), you'll currently need to enable it — go to about:config, set dom.fetch.enabled to true, and restart the browser. To use Fetch in Chrome 41/Opera 28, you need to enable the "Experimental Web Platform Features" pref in chrome://flags.


Yep, had a play around with fetch but it didn't seem ready and acted kind of weird. Can't remember exactly what was wrong as it was a while ago.

I imagine once fetch is decent, most libraries like this won't be hugely useful, but in the mean time, something like xr is a nice way to have a very tiny dependency that makes making AJAX requests just that little bit nicer.


Looks awesome, though the name fetch does work better for GET requests than for POST/PUT/PATCH/DELETE.


Every HTTP request, regardless of method, is implicitly 'fetch'ing an HTTP response.


name itself suggest FETCH is basically used for GET..


Really sad they choose "giant options object" for the api. Makes it pretty difficult to compose.


While I was a little sad about the API too, what would you propose that's better? Connection-less network IO seems like it'd very easily devolve to a "giant options object", and this lets you at least incrementally build that options object on the path from your code to this API.


Fetch doesn't support progress events nor reading headers before processing the body.


Hello, author here. I thought I'd make this because I couldn't find a library that was tiny, and opinionated about using promises and sane defaults (JSON headers, for instance), and exposed the bits of XMLHttpRequest that I wanted. It actually does very little, but provides some nice little helpers to do AJAX requests. Everything is override-able. I'm toying with even making the basic Object.assign and Promise calls injectable too (see this branch: https://github.com/radiosilence/xr/blob/compat/src/xr.js) but it makes the code a bit uglier.

The other handy feature is that it will use whichever Promise library that's available in the global namespace, so as long as that conforms to the spec, it will happily work with it.

Also, title should be lower case, as with most node modules.



Haven't seen it, no. Looks neat, but a bit more complex than what I was going for. This is basically a nicer interface to XHR, intended for people who are happy to read up on the XHR API and use that for anything more complicated.


> * Rejects if not 200.

There are other valid 20x return codes that indicate success, such as 202 Accepted and 204 No Content.


The error logic I tend to use for HTTP status codes is >= 400 as those are explicitly marked as errors in the spec.


Indeed. It's kinda of a thing to think about as, presumably, one would want to do something special in those scenarios.

I guess a discussion would be a bunch of example situations and whether they needed to be treated specially.

I'll make if status >= 200 and < 300, we accept it in the next version.


In xr.js you can see them checking for a status code >= 200 and < 300 so the documentation is wrong, it rejects if not 2XX.

EDIT: Apparently this was changed recently and was actually broken at time of posting.


Isn't 201 the code for a successful resource creation as well?


XHR (XML HTTP Request) always seemed like a sadly particular API name for something that's rarely used to consume XML. From that point-of-view, HR seems like a better name than XR. ;-)


True, but I figured having a two letter function was kinda useful, and HR means other things. Plus, it's a light wrapper for XHR, so hey.

Another nice side effect is that if you use 2-spaces then your promise .then lines up with the initial call...

    xr.get()
      .then(...)


Pretty cool, but I have a nitpick: reject() should be called when the loader throws an exception (e.g. if the response is malformed JSON).


If the loader gets malformed JSON it should throw an exception, which should be seen as a rejection, I think.


What happens after .then? Does xhr get GC'd? Would the inner xhr be considered out of scope?


Ask your JS VM and promise implementation :)




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: