async-listener
async-listener copied to clipboard
othiym23
Make it work in the browser
:D
cc @feross @Matt-Esch
Use case: A long stack traces module that works everywhere.
It's coming, probably sooner rather than later. It's figuring out where the boundaries are and coming up with a compatible way of shimming e.g. XHR that makes it tricky, but I like a challenge.
Also, PRs welcome! :fireworks:
You shouldn't need to manually shim XHR. Just use the http API normally. Browserify can take care of substituting in a shim that maps those calls to the XHR api.
require('request') -> require('http') -> XHR shim is very indirect.
Something like require('xhr') -> uses XMLHttpRequest directly is better for frontend stuff.
We would still need to hook into other things like IndexedDB.
If you're going to write browser-specific code :( then you might as well just use XHR directly. The XHR 2 API is actually not that bad.
@feross var request = typeof window !== 'undefined' ? require('xhr') : (require)('request')
Someone was going to write a single module you could require that did that, xhr is a subset of the request interface.
Every HTTP client I've written so far has had a different implementation for browsers & node.
Hmm... that require('xhr') module sounds useful. Someone should write it!
I really like this approach of take an API that lots of people are familiar with and matching it exactly but making it work in the browser. For example, I did that for the net and dgram APIs in Chrome Apps. See: https://npmjs.org/package/chrome-net and https://npmjs.org/package/chrome-dgram
To work properly, async-listener needs to monkeypatch everywhere that a user expects a call chain to continue but the stack is going to be reset (@jacobgroundwater came up with idea of thinking about it in terms of the stack being reset, which is a lot clearer toe than talking about "bridging async gaps"). It's unavoidably low-level -- the current Node polyfill patches about 30 functions in core, and Trevor's native implementation for 0.12 introduces an entire new, pervasive base class for async wrapping in Node's C++ layer.
If you look at Angular's zone.js, which is a browser equivalent of node-continuation-local-storage, you'll see that it does a bunch of monkeypatching in the browser of its own (and even so, has nowhere near comprehensive browser coverage). I know from talking to coworkers that dealing with XHR is just something you've gotta do, one way or another.
cc @btford zone.js looks like a start to async-listener for browsers :D Lets do this!
^ I was just going to mention zone.js (https://github.com/btford/zone.js/)
Hi guys!
and even so, has nowhere near comprehensive browser coverage
@othiym23 is there any particular API that you know to be unpatched? The goal for zone.js is to be completely comprehensive in wrapping async APIs in the browser.
@btford indexeddb, html5 file system, webrtc, requestAnimationFrame, setImmediate, EventSource, history api, postMessage, webworker, websockets, Webgl.
Some of them may be supported indirectly through EventTarget
Hey, Brian!
I didn't mean browser APIs, although @Raynos's list is pretty exhaustive. I was more responding to the fact that the last time I looked at zone.js you were saying that some browsers / browser versions weren't quite working yet. This was relevant to me in particular because my coworkers are looking for something like a browser version of CLS that works with pretty much every browser ever.
@othiym23 gotcha. The only caveat WRT some browsers not working is a known bug in Chrome. I have a workaround in progress, but my hope was that Chrome would fix the bug before I finished my ugly hack.
Unrelated: I added a link from zone.js's readme to this project. :D
@othiym23 I think there is no way to intercept document.body.onclick = foo in IE6/7. IE8 should be possible with Object.defineProperty working on host objects.
Note: Re-visit https://github.com/strongloop/loopback/issues/1020 once this has completed.
