support for AjaxObservable on node.

[benmonro]

RxJS version:
5

Code to reproduce:

AjaxObservable.create({
                    url,
                    method: 'GET',
                    responseType: 'json',
                    ...options
                });

Expected behavior:
that it send the request, even on the server side (i.e. nodejs)
Actual behavior:
Error saying 'your browser isn't supported'

Additional information:

[kwonoj]

Would you mind to share some snippets to show how did you fill in XMLHttpRequest in your node.js side code?

[benmonro]

I didn't. I had to use isomorphic fetch, though even that has issues. I just did something like:

Observable.from(fetch(...).then(response => response.json())

Basically what I'm asking for is isomorphic AjaxObservable :)

[kwonoj]

I personally do not think that's scope of RxJS itself and consumer may need to fulfill based on isomorphic configurations, but others might have different opinion - /cc @Blesh , @jayphelps .

[benmonro]

I respectfully disagree @kwonoj

If RxJS is offering AjaxObservable and it's supposed to work in Node.js, then AjaxObservable should work in node as well. Either that or it needs to be clearly defined that it's strictly a browser-only feature.

[kwonoj]

To clarify 'scope' I mentioned above, it's matter of providing XMLHttpRequest if it does not exist on certain environment. AjaxObservable will work on node as long as consumer fulfills implementation of XMLHttpRequest.

[benmonro]

Is there any example/docs of this you can provide? I know there are packages in npm that support XMLHttpRequest on node, so if I can pass that in, that'd be fine as well.

[jayphelps]

@benmonro You could use something like https://www.npmjs.com/package/xmlhttprequest

// It needs to be available globally, before RxJS is loaded
global.XMLHttpRequest = require("xmlhttprequest").XMLHttpRequest;

If RxJS is offering AjaxObservable and it's supposed to work in Node.js,

It's not suppose to work in node btw. AjaxObservable is meant as DOM-specific API, AJAX is a browser-based term with XMLHttpRequest a defining characteristic of it. We will likely move it to a separate npm package at some point e.g. rxjs-dom We don't have any immediate plans to add an HTTP request helper for node.js into the core library, but never say never 😉

True isomorphic request libraries (works both on node.js and in browser) is non-trivial since there are no shared APIs. Libraries like isomorphic-fetch abstract that away, so like you discovered it's a fairly good choice for that, but doesn't support cancellation since the fetch() API doesn't.

[benmonro]

well... the thing that threw me off was this in the readme.

Usually when a readme says "Node.js usage" it makes me think it works in node... :) anyway maybe just add something in the docs to the effect of it being intended for the browser and not node...

[benmonro]

@jayphelps... the global xhr hack works. seems like you guys could add that:

if(canUseDOM === false) {
  global.XMLHttpRequest = require("xhr2");
} 

but its all good either way.

[jayphelps]

Glad its working out!

[jayphelps]

Usually when a readme says "Node.js usage" it makes me think it works in node... :) anyway maybe just add something in the docs to the effect of it being intended for the browser and not node...

The observables that require a DOM are namespaced under dom.

import { ajax } from 'rxjs/observable/dom/ajax';

We're also going to remove it from the core library at some point, but since a extremely large number of people use it, it's low on our priority at the moment. Nearly everything else (minor exceptions like the rAF scheduler) work without a DOM, in node. I admit this can be confusing for some. 😞

That said, I think a proposal for a cross-platform http request utility would be awesome. It's unclear if it belongs in core rxjs though--at least until we have a better packaging story. Anyone is welcome to spearhead something by creating their own, e.g. rxjs-http and the conversation can go from there. There are some tough things though, because node's http module is much more robust than XMLHttpRequest, so presumably the ability would need to only what XMLHttpRequest supports to prevent it from not being universal.

[benmonro]

fair enough