Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make it work in the browser #14

Open
Raynos opened this issue Jan 29, 2014 · 18 comments
Open

Make it work in the browser #14

Raynos opened this issue Jan 29, 2014 · 18 comments

Comments

@Raynos
Copy link

Raynos commented Jan 29, 2014

:D

cc @feross @Matt-Esch

Use case: A long stack traces module that works everywhere.

@othiym23
Copy link
Owner

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! 🎆

@feross
Copy link

feross commented Jan 29, 2014

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.

@Raynos
Copy link
Author

Raynos commented Jan 29, 2014

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.

@feross
Copy link

feross commented Jan 29, 2014

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.

@Raynos
Copy link
Author

Raynos commented Jan 29, 2014

@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.

@feross
Copy link

feross commented Jan 29, 2014

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

@Raynos
Copy link
Author

Raynos commented Jan 29, 2014

@feross https://github.com/Raynos/xhr

its a subset of request though.

@feross
Copy link

feross commented Jan 29, 2014

Neat!

@othiym23
Copy link
Owner

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.

@Raynos
Copy link
Author

Raynos commented Jan 29, 2014

cc @btford zone.js looks like a start to async-listener for browsers :D Lets do this!

@megamaddu
Copy link

^ I was just going to mention zone.js (https://github.com/btford/zone.js/)

@btford
Copy link

btford commented Jan 29, 2014

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.

@Raynos
Copy link
Author

Raynos commented Jan 29, 2014

@btford indexeddb, html5 file system, webrtc, requestAnimationFrame, setImmediate, EventSource, history api, postMessage, webworker, websockets, Webgl.

Some of them may be supported indirectly through EventTarget

@othiym23
Copy link
Owner

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.

@btford
Copy link

btford commented Jan 29, 2014

@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

@Raynos
Copy link
Author

Raynos commented Jan 29, 2014

@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.

@a-x-
Copy link

a-x- commented Nov 1, 2014

👍

@pthieu
Copy link

pthieu commented Nov 3, 2016

Note: Re-visit strongloop/loopback#1020 once this has completed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants