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

Closed
lelandrichardson opened this Issue Apr 20, 2015 · 85 comments

Comments

Projects
None yet
@lelandrichardson
Collaborator

lelandrichardson commented Apr 20, 2015

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 comment has been minimized.

Show comment
Hide comment
@nicklockwood

nicklockwood Apr 20, 2015

Contributor

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?

Contributor

nicklockwood commented Apr 20, 2015

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

This comment has been minimized.

Show comment
Hide comment
@vjeux

vjeux Apr 20, 2015

Contributor

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 :)

GLOBAL.XMLHttpRequest = require('XMLHttpRequest');

Contributor

vjeux commented Apr 20, 2015

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 :)

GLOBAL.XMLHttpRequest = require('XMLHttpRequest');

@ide

This comment has been minimized.

Show comment
Hide comment
@ide

ide Apr 20, 2015

Collaborator

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/

Collaborator

ide commented Apr 20, 2015

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

This comment has been minimized.

Show comment
Hide comment
@brentvatne

brentvatne Apr 20, 2015

Collaborator

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

Collaborator

brentvatne commented Apr 20, 2015

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

@lelandrichardson

This comment has been minimized.

Show comment
Hide comment
@lelandrichardson

lelandrichardson Apr 21, 2015

Collaborator

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

Collaborator

lelandrichardson commented Apr 21, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@ide

ide Apr 21, 2015

Collaborator

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:

screenshot 2015-04-21 14 10 19

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.

Collaborator

ide commented Apr 21, 2015

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:

screenshot 2015-04-21 14 10 19

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.

@brentvatne brentvatne closed this May 31, 2015

elliottsj added a commit to elliottsj/react-native that referenced this issue Aug 22, 2015

Enable Chrome '--disable-web-security' flag.
This allows users to inspect network requests in Chrome by commenting
the xhr polyfill in InitializeJavaScriptAppEngine.js:
  facebook#934 (comment)

elliottsj added a commit to elliottsj/react-native that referenced this issue Aug 22, 2015

Enable Chrome '--disable-web-security' flag.
This allows users to inspect network requests in Chrome by commenting
the xhr polyfill in InitializeJavaScriptAppEngine.js:
  facebook#934 (comment)

elliottsj added a commit to elliottsj/react-native that referenced this issue Aug 22, 2015

Enable Chrome '--disable-web-security' flag.
This allows users to inspect network requests in Chrome by commenting
the xhr polyfill in InitializeJavaScriptAppEngine.js:
  facebook#934 (comment)

elliottsj added a commit to elliottsj/react-native that referenced this issue Aug 22, 2015

Add a '--dangerouslyDisableChromeDebuggerWebSecurity' flag to
packager.js to enable Chrome '--disable-web-security' flag.

This allows users to inspect network requests in Chrome by commenting
the xhr polyfill in InitializeJavaScriptAppEngine.js:
  facebook#934 (comment)

Usage:

    node packager.js --dangerouslyDisableChromeDebuggerWebSecurity

or:

    packager.sh --dangerouslyDisableChromeDebuggerWebSecurity

elliottsj added a commit to elliottsj/react-native that referenced this issue Aug 22, 2015

Replace applescript with browser-launcher2
This allows...

1. launching Chrome on platforms other than OS X
2. users to launch their own instance of Chrome (e.g. via command line)
   rather than being forced to use the default instance (i.e.
   `tell application "Chrome"` always used the default instance)

`isDebuggerConnected()` addresses the problem in #510 where the dev tools
would only open once per server session.

Add a '--dangerouslyDisableChromeDebuggerWebSecurity' flag to
packager.js to enable Chrome '--disable-web-security' flag.

This allows users to inspect network requests in Chrome by commenting
the xhr polyfill in InitializeJavaScriptAppEngine.js:
  facebook#934 (comment)

Usage:

    node packager.js --dangerouslyDisableChromeDebuggerWebSecurity

or:

    packager.sh --dangerouslyDisableChromeDebuggerWebSecurity

elliottsj added a commit to elliottsj/react-native that referenced this issue Aug 22, 2015

Replace applescript with browser-launcher2
This allows...

1. launching Chrome on platforms other than OS X
2. users to launch their own instance of Chrome (e.g. via command line)
   rather than being forced to use the default instance (i.e.
   `tell application "Chrome"` always used the default instance)

`isDebuggerConnected()` addresses the problem in #510 where the dev tools
would only open once per server session.

Add a '--dangerouslyDisableChromeDebuggerWebSecurity' flag to
packager.js to enable Chrome '--disable-web-security' flag.

This allows users to inspect network requests in Chrome by commenting
the xhr polyfill in InitializeJavaScriptAppEngine.js:
  facebook#934 (comment)

Usage:

    node packager.js --dangerouslyDisableChromeDebuggerWebSecurity

or:

    packager.sh --dangerouslyDisableChromeDebuggerWebSecurity

elliottsj added a commit to elliottsj/react-native that referenced this issue Aug 23, 2015

Replace applescript with browser-launcher2
This allows...

1. launching Chrome on platforms other than OS X
2. users to launch their own instance of Chrome (e.g. via command line)
   rather than being forced to use the default instance (i.e.
   `tell application "Chrome"` always used the default instance)

`isDebuggerConnected()` addresses the problem in #510 where the dev tools
would only open once per server session.

Add a '--dangerouslyDisableChromeDebuggerWebSecurity' flag to
packager.js to enable Chrome '--disable-web-security' flag.

This allows users to inspect network requests in Chrome by commenting
the xhr polyfill in InitializeJavaScriptAppEngine.js:
  facebook#934 (comment)

Usage:

    node packager.js --dangerouslyDisableChromeDebuggerWebSecurity

or:

    packager.sh --dangerouslyDisableChromeDebuggerWebSecurity

elliottsj added a commit to elliottsj/react-native that referenced this issue Aug 23, 2015

Replace applescript with browser-launcher2
This allows...

1. launching Chrome on platforms other than OS X
2. users to launch their own instance of Chrome (e.g. via command line)
   rather than being forced to use the default instance (i.e.
   `tell application "Chrome"` always used the default instance)

`isDebuggerConnected()` addresses the problem in #510 where the dev tools
would only open once per server session.

Add a '--dangerouslyDisableChromeDebuggerWebSecurity' flag to
packager.js to enable Chrome '--disable-web-security' flag.

This allows users to inspect network requests in Chrome by commenting
the xhr polyfill in InitializeJavaScriptAppEngine.js:
  facebook#934 (comment)

Usage:

    node packager.js --dangerouslyDisableChromeDebuggerWebSecurity

or:

    packager.sh --dangerouslyDisableChromeDebuggerWebSecurity

elliottsj added a commit to elliottsj/react-native that referenced this issue Aug 23, 2015

Replace applescript with browser-launcher2
This allows...

1. launching Chrome on platforms other than OS X
2. users to launch their own instance of Chrome (e.g. via command line)
   rather than being forced to use the default instance (i.e.
   `tell application "Chrome"` always used the default instance)

`isDebuggerConnected()` addresses the problem in #510 where the dev tools
would only open once per server session.

Add a '--dangerouslyDisableChromeDebuggerWebSecurity' flag to
packager.js to enable Chrome '--disable-web-security' flag.

This allows users to inspect network requests in Chrome by commenting
the xhr polyfill in InitializeJavaScriptAppEngine.js:
  facebook#934 (comment)

Usage:

    node packager.js --dangerouslyDisableChromeDebuggerWebSecurity

or:

    packager.sh --dangerouslyDisableChromeDebuggerWebSecurity

elliottsj added a commit to elliottsj/react-native that referenced this issue Aug 25, 2015

Replace applescript with browser-launcher2
This allows...

1. launching Chrome on platforms other than OS X
2. users to launch their own instance of Chrome (e.g. via command line)
   rather than being forced to use the default instance (i.e.
   `tell application "Chrome"` always used the default instance)

`isDebuggerConnected()` addresses the problem in #510 where the dev tools
would only open once per server session.

Add a '--dangerouslyDisableChromeDebuggerWebSecurity' flag to
packager.js to enable Chrome '--disable-web-security' flag.

This allows users to inspect network requests in Chrome by commenting
the xhr polyfill in InitializeJavaScriptAppEngine.js:
  facebook#934 (comment)

Usage:

    node packager.js --dangerouslyDisableChromeDebuggerWebSecurity

or:

    packager.sh --dangerouslyDisableChromeDebuggerWebSecurity

elliottsj added a commit to elliottsj/react-native that referenced this issue Aug 26, 2015

Replace applescript with browser-launcher2
This allows...

1. launching Chrome on platforms other than OS X
2. users to launch their own instance of Chrome (e.g. via command line)
   rather than being forced to use the default instance (i.e.
   `tell application "Chrome"` always used the default instance)

`isDebuggerConnected()` addresses the problem in #510 where the dev tools
would only open once per server session.

Add a '--dangerouslyDisableChromeDebuggerWebSecurity' flag to
packager.js to enable Chrome '--disable-web-security' flag.

This allows users to inspect network requests in Chrome by commenting
the xhr polyfill in InitializeJavaScriptAppEngine.js:
  facebook#934 (comment)

Usage:

    node packager.js --dangerouslyDisableChromeDebuggerWebSecurity

or:

    packager.sh --dangerouslyDisableChromeDebuggerWebSecurity

elliottsj added a commit to elliottsj/react-native that referenced this issue Sep 14, 2015

Replace applescript with browser-launcher2
This allows...

1. launching Chrome on platforms other than OS X
2. users to launch their own instance of Chrome (e.g. via command line)
   rather than being forced to use the default instance (i.e.
   `tell application "Chrome"` always used the default instance)

`isDebuggerConnected()` addresses the problem in #510 where the dev tools
would only open once per server session.

Add a '--dangerouslyDisableChromeDebuggerWebSecurity' flag to
packager.js to enable Chrome '--disable-web-security' flag.

This allows users to inspect network requests in Chrome by commenting
the xhr polyfill in InitializeJavaScriptAppEngine.js:
  facebook#934 (comment)

Usage:

    node packager.js --dangerouslyDisableChromeDebuggerWebSecurity

or:

    packager.sh --dangerouslyDisableChromeDebuggerWebSecurity

elliottsj added a commit to elliottsj/react-native that referenced this issue Sep 19, 2015

Replace applescript with browser-launcher2
This allows...

1. launching Chrome on platforms other than OS X
2. users to launch their own instance of Chrome (e.g. via command line)
   rather than being forced to use the default instance (i.e.
   `tell application "Chrome"` always used the default instance)

`isDebuggerConnected()` addresses the problem in #510 where the dev tools
would only open once per server session.

Add a '--dangerouslyDisableChromeDebuggerWebSecurity' flag to
packager.js to enable Chrome '--disable-web-security' flag.

This allows users to inspect network requests in Chrome by commenting
the xhr polyfill in InitializeJavaScriptAppEngine.js:
  facebook#934 (comment)

Usage:

    node packager.js --dangerouslyDisableChromeDebuggerWebSecurity

or:

    packager.sh --dangerouslyDisableChromeDebuggerWebSecurity
@kushal

This comment has been minimized.

Show comment
Hide comment
@kushal

kushal Sep 23, 2015

Contributor

I wonder if the original implementation of XHR could be saved somewhere else in GLOBALS, e.g. GLOBALS.originalXhr = XMLHttpRequest ? Then it would be possible to undo the polyfill in application code rather than needing to patch and unpatch the RN libraries?

Contributor

kushal commented Sep 23, 2015

I wonder if the original implementation of XHR could be saved somewhere else in GLOBALS, e.g. GLOBALS.originalXhr = XMLHttpRequest ? Then it would be possible to undo the polyfill in application code rather than needing to patch and unpatch the RN libraries?

elliottsj added a commit to elliottsj/react-native that referenced this issue Sep 27, 2015

Replace applescript with browser-launcher2
This allows...

1. launching Chrome on platforms other than OS X
2. users to launch their own instance of Chrome (e.g. via command line)
   rather than being forced to use the default instance (i.e.
   `tell application "Chrome"` always used the default instance)

`isDebuggerConnected()` addresses the problem in #510 where the dev tools
would only open once per server session.

Add a '--dangerouslyDisableChromeDebuggerWebSecurity' flag to
packager.js to enable Chrome '--disable-web-security' flag.

This allows users to inspect network requests in Chrome by commenting
the xhr polyfill in InitializeJavaScriptAppEngine.js:
  facebook#934 (comment)

Usage:

    node packager.js --dangerouslyDisableChromeDebuggerWebSecurity

or:

    packager.sh --dangerouslyDisableChromeDebuggerWebSecurity

elliottsj added a commit to elliottsj/react-native that referenced this issue Sep 27, 2015

Replace applescript with browser-launcher2
This allows...

1. launching Chrome on platforms other than OS X
2. users to launch their own instance of Chrome (e.g. via command line)
   rather than being forced to use the default instance (i.e.
   `tell application "Chrome"` always used the default instance)

`isDebuggerConnected()` addresses the problem in #510 where the dev tools
would only open once per server session.

Add a '--dangerouslyDisableChromeDebuggerWebSecurity' flag to
packager.js to enable Chrome '--disable-web-security' flag.

This allows users to inspect network requests in Chrome by commenting
the xhr polyfill in InitializeJavaScriptAppEngine.js:
  facebook#934 (comment)

Usage:

    node packager.js --dangerouslyDisableChromeDebuggerWebSecurity

or:

    packager.sh --dangerouslyDisableChromeDebuggerWebSecurity
@JAStanton

This comment has been minimized.

Show comment
Hide comment
@JAStanton

JAStanton Oct 5, 2015

Contributor

Out of curiosity why was this issue closed? Seems like it's still a very useful to have feature. The workaround is pretty dangerous.

Contributor

JAStanton commented Oct 5, 2015

Out of curiosity why was this issue closed? Seems like it's still a very useful to have feature. The workaround is pretty dangerous.

@vjeux vjeux reopened this Oct 5, 2015

@vjeux

This comment has been minimized.

Show comment
Hide comment
@vjeux

vjeux Oct 5, 2015

Contributor

You are right, this is a useful feature to have. Reopening it. @brentvatne is there a duplicate one somewhere?

Contributor

vjeux commented Oct 5, 2015

You are right, this is a useful feature to have. Reopening it. @brentvatne is there a duplicate one somewhere?

@ide

This comment has been minimized.

Show comment
Hide comment
@ide

ide Oct 5, 2015

Collaborator

Is there a good fix? Here are all the ideas I have:

  • Use Charles Proxy or something similar. I do this and find it works well since you can capture all traffic, and it works across all RN environments.
  • Don't use Chrome since people have important cookies saved there. Run in some kind of sandboxed Electron environment instead since you don't use Electron to log into your bank.
  • Run a proxy server and rewrite all URLs to go through it. Maybe can be done cleanly.

Kind of depends how far you want to go with the Chrome tools compared to investing in the JSC ones instead.

Collaborator

ide commented Oct 5, 2015

Is there a good fix? Here are all the ideas I have:

  • Use Charles Proxy or something similar. I do this and find it works well since you can capture all traffic, and it works across all RN environments.
  • Don't use Chrome since people have important cookies saved there. Run in some kind of sandboxed Electron environment instead since you don't use Electron to log into your bank.
  • Run a proxy server and rewrite all URLs to go through it. Maybe can be done cleanly.

Kind of depends how far you want to go with the Chrome tools compared to investing in the JSC ones instead.

@kushal

This comment has been minimized.

Show comment
Hide comment
@kushal

kushal Oct 6, 2015

Contributor

These issues only occur in the absence of CORS, right? Maybe it's possible
to detect CORS-compatible domains and route appropriately?

On Mon, Oct 5, 2015 at 4:53 PM James Ide notifications@github.com wrote:

Is there a good fix? Here are all the ideas I have:

  • Use Charles Proxy or something similar. I do this and find it works
    well since you can capture all traffic, and it works across all RN
    environments.
  • Don't use Chrome since people have important cookies saved there.
    Run in some kind of sandboxed Electron environment instead since you don't
    use Electron to log into your bank.
  • Run a proxy server and rewrite all URLs to go through it. Maybe can
    be done cleanly.

Kind of depends how far you want to go with the Chrome tools compared to
investing in the JSC ones instead.


Reply to this email directly or view it on GitHub
#934 (comment)
.

Contributor

kushal commented Oct 6, 2015

These issues only occur in the absence of CORS, right? Maybe it's possible
to detect CORS-compatible domains and route appropriately?

On Mon, Oct 5, 2015 at 4:53 PM James Ide notifications@github.com wrote:

Is there a good fix? Here are all the ideas I have:

  • Use Charles Proxy or something similar. I do this and find it works
    well since you can capture all traffic, and it works across all RN
    environments.
  • Don't use Chrome since people have important cookies saved there.
    Run in some kind of sandboxed Electron environment instead since you don't
    use Electron to log into your bank.
  • Run a proxy server and rewrite all URLs to go through it. Maybe can
    be done cleanly.

Kind of depends how far you want to go with the Chrome tools compared to
investing in the JSC ones instead.


Reply to this email directly or view it on GitHub
#934 (comment)
.

@ide

This comment has been minimized.

Show comment
Hide comment
@ide

ide Oct 6, 2015

Collaborator

That's a good point... actually what if we just didn't solve the CORS issue? 1/ if you're talking to your own server, send back the right CORS header w/1-3 lines of code. 2/ if you're talking to someone else's server w/out the right CORS headers then you have lots of workarounds (proxy server, disable web security, Charles Proxy).

Collaborator

ide commented Oct 6, 2015

That's a good point... actually what if we just didn't solve the CORS issue? 1/ if you're talking to your own server, send back the right CORS header w/1-3 lines of code. 2/ if you're talking to someone else's server w/out the right CORS headers then you have lots of workarounds (proxy server, disable web security, Charles Proxy).

@nevir

This comment has been minimized.

Show comment
Hide comment
@nevir

nevir Oct 8, 2015

Contributor

👍 Would prefer that

Contributor

nevir commented Oct 8, 2015

👍 Would prefer that

@ide

This comment has been minimized.

Show comment
Hide comment
@ide

ide Oct 8, 2015

Collaborator

So if we ignore CORS issues we just need a way to tell RN not to polyfill XHR and fetch.

Do we want to do this by default? Pro: good debugging experience. Con: i'm concerned about getting too attached to Chrome's behavior. RN can do a better job in a lot of ways that make more sense for mobile. So I don't really want to set the expectation that if something works in RN it will totally work in other environments.

We could also expose the original XHR/fetch implementations as global.originalFetch and global.originalXMLHttpRequest, and let users set global.fetch = global.originalFetch.

Collaborator

ide commented Oct 8, 2015

So if we ignore CORS issues we just need a way to tell RN not to polyfill XHR and fetch.

Do we want to do this by default? Pro: good debugging experience. Con: i'm concerned about getting too attached to Chrome's behavior. RN can do a better job in a lot of ways that make more sense for mobile. So I don't really want to set the expectation that if something works in RN it will totally work in other environments.

We could also expose the original XHR/fetch implementations as global.originalFetch and global.originalXMLHttpRequest, and let users set global.fetch = global.originalFetch.

@nevir

This comment has been minimized.

Show comment
Hide comment
@nevir

nevir Oct 8, 2015

Contributor

Well, not polyfilling allows users to polyfill themselves if they want to (e.g. if they're in their debug environment, they may want to).

Aren't we already pretty attached to Chrome behavior anyway (with code being executed in that context when it's active)? Might as well go all the way and make that even more consistent - even if that makes it less consistent with a JSC environment

Contributor

nevir commented Oct 8, 2015

Well, not polyfilling allows users to polyfill themselves if they want to (e.g. if they're in their debug environment, they may want to).

Aren't we already pretty attached to Chrome behavior anyway (with code being executed in that context when it's active)? Might as well go all the way and make that even more consistent - even if that makes it less consistent with a JSC environment

@nevir

This comment has been minimized.

Show comment
Hide comment
@nevir

nevir Oct 8, 2015

Contributor

Simply exposing the original implementations seems like a reasonable approach too, if there are too many concerns going further down the Chrome rabbit-hole

Contributor

nevir commented Oct 8, 2015

Simply exposing the original implementations seems like a reasonable approach too, if there are too many concerns going further down the Chrome rabbit-hole

@vjeux

This comment has been minimized.

Show comment
Hide comment
@vjeux

vjeux Oct 8, 2015

Contributor

We could also expose the original XHR/fetch implementations as global.originalFetch and global.originalXMLHttpRequest, and let users set global.fetch = global.originalFetch.

Seems like the best solution. If you know what you are doing, just put that js line at the top of your file and boom, you use chrome to download and have to deal with XHR yourself.

Contributor

vjeux commented Oct 8, 2015

We could also expose the original XHR/fetch implementations as global.originalFetch and global.originalXMLHttpRequest, and let users set global.fetch = global.originalFetch.

Seems like the best solution. If you know what you are doing, just put that js line at the top of your file and boom, you use chrome to download and have to deal with XHR yourself.

@JAStanton

This comment has been minimized.

Show comment
Hide comment
@JAStanton

JAStanton Oct 8, 2015

Contributor

Sounds great! As a dev I can deal with CORS myself. I would love to be able to override with just one line. 👍

Contributor

JAStanton commented Oct 8, 2015

Sounds great! As a dev I can deal with CORS myself. I would love to be able to override with just one line. 👍

@vjeux

This comment has been minimized.

Show comment
Hide comment
@vjeux

vjeux Oct 8, 2015

Contributor

You can do that today btw, in your app entry point, write

var _oldXHR = XMLHTTPRequest;
require('react-native');
XMLHTTPRequest = _oldXHR;

should do the trick. We initialize all those variables the first time we require react-native right now (I want to change it to be there before, but that's another story)

Contributor

vjeux commented Oct 8, 2015

You can do that today btw, in your app entry point, write

var _oldXHR = XMLHTTPRequest;
require('react-native');
XMLHTTPRequest = _oldXHR;

should do the trick. We initialize all those variables the first time we require react-native right now (I want to change it to be there before, but that's another story)

@ide

This comment has been minimized.

Show comment
Hide comment
@ide

ide Oct 8, 2015

Collaborator

Aren't we already pretty attached to Chrome behavior anyway (with code being executed in that context when it's active)?

Well I'm interested in potentially killing the Chrome dev tools and replacing them with Node.js dev tools (you'd run in a Node context). We're already moving away from a Chrome environment by running the RN code in a WebWorker.

Anyone want to send a PR for the proposal of exposing the original implementations if they exist? (Also in advance -- would we want these to be non-enumerable properties? Doesn't get us anything I think but also doesn't hurt.)

Collaborator

ide commented Oct 8, 2015

Aren't we already pretty attached to Chrome behavior anyway (with code being executed in that context when it's active)?

Well I'm interested in potentially killing the Chrome dev tools and replacing them with Node.js dev tools (you'd run in a Node context). We're already moving away from a Chrome environment by running the RN code in a WebWorker.

Anyone want to send a PR for the proposal of exposing the original implementations if they exist? (Also in advance -- would we want these to be non-enumerable properties? Doesn't get us anything I think but also doesn't hurt.)

@brunolemos

This comment has been minimized.

Show comment
Hide comment
@brunolemos

brunolemos Dec 24, 2016

Contributor

This feature would be awesome.

I'm currently doing this to log all fetch requests and responses:

// fetch logger
global._fetch = fetch;
global.fetch = function(uri, options, ...args) {
  return global._fetch(uri, options, ...args).then((response) => {
    console.log('Fetch', { request: { uri, options, ...args }, response });
    return response;
  });
};

Screen Shot 2016-12-23 at 23.57.02.png

Contributor

brunolemos commented Dec 24, 2016

This feature would be awesome.

I'm currently doing this to log all fetch requests and responses:

// fetch logger
global._fetch = fetch;
global.fetch = function(uri, options, ...args) {
  return global._fetch(uri, options, ...args).then((response) => {
    console.log('Fetch', { request: { uri, options, ...args }, response });
    return response;
  });
};

Screen Shot 2016-12-23 at 23.57.02.png

@jaisonveneri

This comment has been minimized.

Show comment
Hide comment

@brunolemos Very nice!

@brunolemos

This comment has been minimized.

Show comment
Hide comment
@brunolemos

brunolemos Dec 30, 2016

Contributor

Now I'm using this much better solution:

GLOBAL.XMLHttpRequest = GLOBAL.originalXMLHttpRequest || GLOBAL.XMLHttpRequest;

The requests will appear on Chrome Network tab if the Remote JS Debugging is enabled.
EDIT: If the response body is not appearing to you, use the answer above as a complement.

--
🐦 Twitter: @brunolemos

Contributor

brunolemos commented Dec 30, 2016

Now I'm using this much better solution:

GLOBAL.XMLHttpRequest = GLOBAL.originalXMLHttpRequest || GLOBAL.XMLHttpRequest;

The requests will appear on Chrome Network tab if the Remote JS Debugging is enabled.
EDIT: If the response body is not appearing to you, use the answer above as a complement.

--
🐦 Twitter: @brunolemos

@jaredly

This comment has been minimized.

Show comment
Hide comment
@jaredly

jaredly Jan 6, 2017

Contributor

^ this has CORS implications, right?

Contributor

jaredly commented Jan 6, 2017

^ this has CORS implications, right?

@xwartz

This comment has been minimized.

Show comment
Hide comment
@xwartz

xwartz Jan 6, 2017

@jaredly yes.

@brunolemos this has CORS Access-Control-Allow-Origin problem.

xwartz commented Jan 6, 2017

@jaredly yes.

@brunolemos this has CORS Access-Control-Allow-Origin problem.

@brunolemos

This comment has been minimized.

Show comment
Hide comment
@brunolemos

brunolemos Jan 6, 2017

Contributor

I rarely need to debug api calls, but didn't have any cross domain problems yet with this solution workaround. Just to be clear, I comment this line of code after using it.

Contributor

brunolemos commented Jan 6, 2017

I rarely need to debug api calls, but didn't have any cross domain problems yet with this solution workaround. Just to be clear, I comment this line of code after using it.

@srhise

This comment has been minimized.

Show comment
Hide comment
@srhise

srhise Jan 6, 2017

srhise commented Jan 6, 2017

@tomaszpolanski

This comment has been minimized.

Show comment
Hide comment
@tomaszpolanski

tomaszpolanski Jan 6, 2017

@srhise For me it worked properly when I've added it, for example, in the index.android.js just after imports:

//...
import React from 'react'

GLOBAL.XMLHttpRequest = GLOBAL.originalXMLHttpRequest || GLOBAL.XMLHttpRequest

@srhise For me it worked properly when I've added it, for example, in the index.android.js just after imports:

//...
import React from 'react'

GLOBAL.XMLHttpRequest = GLOBAL.originalXMLHttpRequest || GLOBAL.XMLHttpRequest

@lhrolim lhrolim referenced this issue in auth0/react-native-auth0 Jan 7, 2017

Closed

Authentication API userInfo causes Unexpected token #2

@max-mykhailenko

This comment has been minimized.

Show comment
Hide comment
@max-mykhailenko

max-mykhailenko Feb 1, 2017

@brunolemos Do I need to do additional setup in chrome? I install plugin, but not understand correct settings in it. Can you add screenshot with right configuration?

@brunolemos Do I need to do additional setup in chrome? I install plugin, but not understand correct settings in it. Can you add screenshot with right configuration?

@rikur

This comment has been minimized.

Show comment
Hide comment
@rikur

rikur Feb 8, 2017

I'm still seeing [Object object] for FormData requests with files in them.

We're also missing the first request we send to the server right at the start of the application. When does "Debug JS Remotely" bridge get formed? It seems to me that the request happens before the remote debugging bridge is initialized and I'm not quite sure how to detect if the bridge is up or not.

rikur commented Feb 8, 2017

I'm still seeing [Object object] for FormData requests with files in them.

We're also missing the first request we send to the server right at the start of the application. When does "Debug JS Remotely" bridge get formed? It seems to me that the request happens before the remote debugging bridge is initialized and I'm not quite sure how to detect if the bridge is up or not.

@master-atul

This comment has been minimized.

Show comment
Hide comment
@master-atul

master-atul Feb 15, 2017

@brunolemos Your solution works best ! Easy and clean ! Thanks :)

@brunolemos Your solution works best ! Easy and clean ! Thanks :)

@chemitaxis

This comment has been minimized.

Show comment
Hide comment
@chemitaxis

chemitaxis Feb 27, 2017

Thanks for the solution ;)

Thanks for the solution ;)

@trazyn

This comment has been minimized.

Show comment
Hide comment

trazyn commented Mar 1, 2017

@brunolemos thanks guys

@SeanDunford

This comment has been minimized.

Show comment
Hide comment
@seanadkinson

This comment has been minimized.

Show comment
Hide comment
@seanadkinson

seanadkinson Apr 20, 2017

I see the Network requests coming through using the proposed solution, but I don't see anything in Response or Preview tabs. Is anyone seeing the actual response payload in the Network tab? I tried on Chrome and Canary, same result for both.

I see the Network requests coming through using the proposed solution, but I don't see anything in Response or Preview tabs. Is anyone seeing the actual response payload in the Network tab? I tried on Chrome and Canary, same result for both.

@srhise

This comment has been minimized.

Show comment
Hide comment
@srhise

srhise Apr 20, 2017

srhise commented Apr 20, 2017

@peterjacobson

This comment has been minimized.

Show comment
Hide comment
@peterjacobson

peterjacobson May 2, 2017

Using @brunolemos's
GLOBAL.XMLHttpRequest = GLOBAL.originalXMLHttpRequest || GLOBAL.XMLHttpRequest
in the index.ios.js as recommended by @tomaszpolanski:

I see the network requests in Chrome Dev Tools Network Tab,
BUT get the console error:

XMLHttpRequest cannot load https://<site>.com/api/users.  
Response to preflight request doesn't pass access control check: 
   No 'Access-Control-Allow-Origin' header is present on the requested resource. 
Origin 'http://localhost:8081' is therefore not allowed access. 
The response had HTTP status code 405.

Which breaks all requests (so breaks the app)
Any thoughts on how to add a header, or resolve this issue?

peterjacobson commented May 2, 2017

Using @brunolemos's
GLOBAL.XMLHttpRequest = GLOBAL.originalXMLHttpRequest || GLOBAL.XMLHttpRequest
in the index.ios.js as recommended by @tomaszpolanski:

I see the network requests in Chrome Dev Tools Network Tab,
BUT get the console error:

XMLHttpRequest cannot load https://<site>.com/api/users.  
Response to preflight request doesn't pass access control check: 
   No 'Access-Control-Allow-Origin' header is present on the requested resource. 
Origin 'http://localhost:8081' is therefore not allowed access. 
The response had HTTP status code 405.

Which breaks all requests (so breaks the app)
Any thoughts on how to add a header, or resolve this issue?

@Jacse

This comment has been minimized.

Show comment
Hide comment
@Jacse

Jacse May 10, 2017

@peterjacobson start a new instance of Chrome with flags --disable-web-security --user-data-dir. Makes sure you close all instances of Chrome first. E.g. on Windows: "C:\Program Files (x86)\Google\Chrome\Application\Chrome.exe" --disable-web-security --user-data-dir

Jacse commented May 10, 2017

@peterjacobson start a new instance of Chrome with flags --disable-web-security --user-data-dir. Makes sure you close all instances of Chrome first. E.g. on Windows: "C:\Program Files (x86)\Google\Chrome\Application\Chrome.exe" --disable-web-security --user-data-dir

@oliverbenns

This comment has been minimized.

Show comment
Hide comment
@oliverbenns

oliverbenns May 25, 2017

@brunolemos solution works well. But doesn't gives response bodies for some reason.

@brunolemos solution works well. But doesn't gives response bodies for some reason.

@srhise

This comment has been minimized.

Show comment
Hide comment
@srhise

srhise May 25, 2017

srhise commented May 25, 2017

@beeant

This comment has been minimized.

Show comment
Hide comment

beeant commented Jun 10, 2017

@brunolemos same here

@nsisodiya

This comment has been minimized.

Show comment
Hide comment
@nsisodiya

nsisodiya Jun 10, 2017

Cannot believe, this is 2017, and we do not have a solution to this.

Cannot believe, this is 2017, and we do not have a solution to this.

@brunolemos

This comment has been minimized.

Show comment
Hide comment
@brunolemos

brunolemos Jun 10, 2017

Contributor

@srhise @beeant @nsisodiya If this doesn't show the body to you use this as a complement

Contributor

brunolemos commented Jun 10, 2017

@srhise @beeant @nsisodiya If this doesn't show the body to you use this as a complement

@nsisodiya

This comment has been minimized.

Show comment
Hide comment
@nsisodiya

nsisodiya Jun 11, 2017

@brunolemos

This comment has been minimized.

Show comment
Hide comment
@brunolemos

brunolemos Jun 11, 2017

Contributor

@nsisodiya if that's a need to you, maybe you can dive in to the react native source code and help with a pull request

Contributor

brunolemos commented Jun 11, 2017

@nsisodiya if that's a need to you, maybe you can dive in to the react native source code and help with a pull request

@nsisodiya

This comment has been minimized.

Show comment
Hide comment
@nsisodiya

nsisodiya Jun 11, 2017

@beeant

This comment has been minimized.

Show comment
Hide comment
@beeant

beeant Jun 11, 2017

@brunobar79 I've been using that other way but it slows down the app when debugging because of console.log

beeant commented Jun 11, 2017

@brunobar79 I've been using that other way but it slows down the app when debugging because of console.log

@mschipperheyn

This comment has been minimized.

Show comment
Hide comment
@mschipperheyn

mschipperheyn Jul 18, 2017

@peterjacobson

GLOBAL.XMLHttpRequest = GLOBAL.originalXMLHttpRequest || GLOBAL.XMLHttpRequest

I don't get the headers passed through that way

@peterjacobson

GLOBAL.XMLHttpRequest = GLOBAL.originalXMLHttpRequest || GLOBAL.XMLHttpRequest

I don't get the headers passed through that way

@ospfranco

This comment has been minimized.

Show comment
Hide comment
@ospfranco

ospfranco Dec 23, 2017

None of the proposed solutions is working for me, quite amazed that react-native doesn’t have a way to do something as simple as this.

None of the proposed solutions is working for me, quite amazed that react-native doesn’t have a way to do something as simple as this.

@pavanmehta91

This comment has been minimized.

Show comment
Hide comment
@pavanmehta91

pavanmehta91 Jan 10, 2018

@brunolemos Your solution does work. But there's one issue when doing multi-part file XHR requests. They fail when we use GLOBAL.XMLHttpRequest = GLOBAL.originalXMLHttpRequest || GLOBAL.XMLHttpRequest

@brunolemos Your solution does work. But there's one issue when doing multi-part file XHR requests. They fail when we use GLOBAL.XMLHttpRequest = GLOBAL.originalXMLHttpRequest || GLOBAL.XMLHttpRequest

@artem-russkikh artem-russkikh referenced this issue in infinitered/ignite-ir-boilerplate-andross Mar 22, 2018

Merged

Updates Reactotron to the latest version & techniques. #59

@lucaszanella

This comment has been minimized.

Show comment
Hide comment
@lucaszanella

lucaszanella Mar 27, 2018

Not working with me. I can see the requests on chrome network monitor but they fail and then an error appears on the phone

Not working with me. I can see the requests on chrome network monitor but they fail and then an error appears on the phone

@kashishgrover

This comment has been minimized.

Show comment
Hide comment
@kashishgrover

kashishgrover Jun 28, 2018

Seems like there isn't a proper solution so far. Meanwhile, I made @brunolemos's solution just a little bit prettier. My logs are flooded anyway, and I need something like this. Don't mind me. :)

const showApiCalls = () => {
  const baseUrl = 'http://www.mocky.io/';
  global._fetch = fetch;
  global.fetch = async (uri, options, ...args) => {
    const response = await global._fetch(uri, options, ...args);
    if (uri.includes(baseUrl)) {
      console.log(
        '🔵 API Call: ',
        uri,
        { request: { uri }, response },
      );
    }
    return response;
  };
};

kashishgrover commented Jun 28, 2018

Seems like there isn't a proper solution so far. Meanwhile, I made @brunolemos's solution just a little bit prettier. My logs are flooded anyway, and I need something like this. Don't mind me. :)

const showApiCalls = () => {
  const baseUrl = 'http://www.mocky.io/';
  global._fetch = fetch;
  global.fetch = async (uri, options, ...args) => {
    const response = await global._fetch(uri, options, ...args);
    if (uri.includes(baseUrl)) {
      console.log(
        '🔵 API Call: ',
        uri,
        { request: { uri }, response },
      );
    }
    return response;
  };
};
@pencilcheck

This comment has been minimized.

Show comment
Hide comment
@pencilcheck

pencilcheck Jul 7, 2018

Adding GLOBAL.XMLHttpRequest = GLOBAL.originalXMLHttpRequest || GLOBAL.XMLHttpRequest; works but also introduces other issues which is more severe.

Now network requests will not work at all when react native debugger is turned on with this line in place.

Using react-native 0.47 on macOS

Adding GLOBAL.XMLHttpRequest = GLOBAL.originalXMLHttpRequest || GLOBAL.XMLHttpRequest; works but also introduces other issues which is more severe.

Now network requests will not work at all when react native debugger is turned on with this line in place.

Using react-native 0.47 on macOS

@kashishgrover

This comment has been minimized.

Show comment
Hide comment
@kashishgrover

kashishgrover Jul 9, 2018

screen shot 2018-07-09 at 3 06 25 pm

I didn't realise until a few days back how well network calls work in React Native Debugger. You just have to enable them by selecting Enable Network Inspect in the options. Try this. I absolutely love React Native Debugger. ❤️

kashishgrover commented Jul 9, 2018

screen shot 2018-07-09 at 3 06 25 pm

I didn't realise until a few days back how well network calls work in React Native Debugger. You just have to enable them by selecting Enable Network Inspect in the options. Try this. I absolutely love React Native Debugger. ❤️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment