Support responseType = 'arraybuffer'

[danvk]

When you set xhr.responseType = 'arraybuffer', xhr.response should be an ArrayBuffer, not a string. It looks like faux-jax does not emulate this behavior (xhr.response remains a string when I set the responseType property).

[vvo]

can you do a PR for this? would be awesome. the readme explains how to launch the dev env (npm run dev)

then follow the spec, should not be that hard at all!

[terinjokes]

Ditto for responseType = 'blob'. Should setResponseBody allow a compatible non-string argument if in one of the other modes?

[vvo]

Should setResponseBody allow a compatible non-string argument if in one of the other modes?

Can you detail this? Do not understand what you mean.

[terinjokes]

Can you detail this? Do not understand what you mean.

If the responseType is set to something other than "text" or "", it would be nice if we could set the response body to an instance of that type directly. Otherwise if I want to respond with a Blob, I have to convert and set the response body to a binary string just for faux-ajax to convert it back to a Blob.

[vvo]

I have to convert and set the response body to a binary string just for faux-ajax to convert it back to a Blob.

I think we should keep it this way and let the user do his own helper functions to do this.

The thing is that we must be as close as possible to the way browser will receive a response.

On the network there's no ArrayBuffer or JSON objects, only "strings".

It will also require more work for faux-jax than just passing references: we will have to convert various instances to string and then parse them again at the end.

In progress events, you must be able to access the current responseText, so that for instance you can do streaming JSON parsing from an XHR (well as faux-jax is nearly synchronous I guess, that's not feasible right now).

In the end someone will have to stringify instances and parse them back. So that we also clone objects.

What do you think?

[vvo]

Also that's a separate issue :)