Show network requests such as fetch, WebSocket etc. in chrome dev tools

[lelandrichardson]

I've just taken a deep dive into React Native this past weekend, and (as suspected) I'm liking it a lot. Great job!

When I first started working with the fetch API to request resources, I had chrome dev-tools opened and I was really hoping that I would be able to inspect the web requests happening in chrome's "Network" tab. Of course, that is not the case :(

I am not sure what sort of hoops would have to be jumped through in order to make this a possibility, but I think it would be a great addition if it is possible. Adding this would bring the mobile development workflow even closer to the web development workflow, which RN has done such a good job of doing thus far. This is a huge pain-point for me in normal objective-c development as well, since there are not really any good free HTTP-debugging apps out there for mac OS, and even if there are, that would be yet-another-window to have open at all times.

[nicklockwood]

This is an interesting. Idea. We polyfill the XMLHttpRequest API using native code when running in the JavaScriptCore executor, because XHR is a browser API and as such, simply doesn't exist in a pure-JS context.

But in theory, when running in a browser, we could offer the option to un-polyfill the API, and use the browser's HTTP request infrastructure instead. It would have to be an option that was separate from normal debug mode, because it wouldn't be a true test of the app behaviour (it would mask differences in the native XHR implementation), but it seems like a reasonable thing to want to do.

Another option would be to simply pipe request/response headers and bodies through to the JS console so they can be inspected. That would be simpler, but perhaps less useful?

Thoughts, @vjeux?

[vjeux]

I had it un-polyfilled before but you run into CORS issues. If you correctly setup CORS then you can comment this line and see all the http requests in the chrome dev tools :)

react-native/Libraries/JavaScriptAppEngine/Initialization/InitializeJavaScriptAppEngine.js

Line 127 in 2bb10cd

GLOBAL.XMLHttpRequest = require('XMLHttpRequest');

[ide]

For convenience it sounds like you can also turn off CORS (and maybe more - use at your own risk) by running Chrome with --disable-web-security. https://blog.nraboy.com/2014/08/bypass-cors-errors-testing-apis-locally/

[brentvatne]

@vjeux - very cool how easy that is to accomplish!

[lelandrichardson]

@ide that's a nifty command line argument. Do you know if I would I be able to just launch chrome with that command line arg and then whenever I launch the debugger from RN it would just work? Or is there a place in the RN source code where I would want to add that command line argument? I will try and test out the former along with @vjeux 's changes myself when I get a chance.

[ide]

I got this working in a crude way. First quit Chrome so none of its processes are running. I didn't find a way to apply the CLI switch to a single tab. Then run:

"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" --disable-web-security

note: a malicious site now can get your gmail, facebook, bank account, etc if you are logged in, so after you're done be sure to restart Chrome. also why I think it's better just to set up CORS if you own the endpoint or write a proxy.

Comment out the line in InitializeJavaScriptAppEngine.js mentioned above in this thread and then when you enable Chrome debugging in an app you get this:

It seems useful to track down issues like too many network requests or forgetting to gzip the responses but it won't help with debugging issues with Cocoa's networking stack that users are running. Also for more than basic HTTP requests (ex: NSURLSession) then advanced apps won't use the XMLHttpRequest polyfill. So, I think it's a good tool to have but Charles Proxy or getting PonyDebugger hooked up looks more fruitful in the longer term.