Suppress "Download the React DevTools" log for a better development experience

[tjx666]

React version: 18.0.0

Steps To Reproduce

1. open a remote debug chrome devtools window
2. the message will show

Link to code example:

The current behavior

The expected behavior

No this message. Chrome extension can't be used in remote debug window

[tjx666]

Set REACT_DEVTOOLS_GLOBAL_HOOK environment is not a good idea because pmmmwh/react-refresh-webpack-plugin#475

[lunaruan]

Hey! Thanks for reporting this issue. I'm a little unclear about your issue. Could you give more details on how to reproduce? What do you mean by a remote debug Chrome DevTools window? Why can't Chrome extensions be used there?

[tjx666]

You can see there is no react components and profiler tab in the devtools. Because I using the devtools to remote debug.

I open the devtools from this page:

I using react in CEP environment, CEP environment is a little like nwjs.

[tjx666]

To reproduce this is a little complex, you may need to install photoshop or affect and config the debug model...

[bvaughn]

Set REACT_DEVTOOLS_GLOBAL_HOOK environment is not a good idea because pmmmwh/react-refresh-webpack-plugin#475

Right. __REACT_DEVTOOLS_GLOBAL_HOOK__ is a global variable (because of how the extension works) but it should be thought of as React internals and should not be overridden.

React DOM logs a suggestion to install React DevTools on environments where DevTools isn't installed, which it identifies by checking to see if __REACT_DEVTOOLS_GLOBAL_HOOK__ has been defined. In the "remote" environment you're describing, __REACT_DEVTOOLS_GLOBAL_HOOK__ is not defined, so React logs the message.

Regarding the developer experience, I understand why it might be a small inconvenience although there are many other things that also log in DEV mode (like the HMR logs in your screenshot above). If it's a huge problem, we could add an opt-out mechanism (probably another global variable) but I'm not convinced that's worth it.

[gaearon]

Right. REACT_DEVTOOLS_GLOBAL_HOOK is a global variable (because of how the extension works) but it should be thought of as React internals and should not be overridden.

I did suggest overriding it in the past as a workaround for this log: #11448. I'm not particularly fond of that approach, but wanted to share as an explanation for why people are trying that pattern. It's referenced in #3877 which people find by googling.

[bvaughn]

@gaearon Maybe worth editing that old message to remove the recommendation (or clarify that it technically works but we don't recommend it) if it's causing confusion?

Overriding the hook feels kind of sketchy to me as it could easily cause runtime errors that get misattributed to React or DevTools. (This has happened before, although I don't remember the issue numbers.)

[gaearon]

If we remove the suggestion, it feels like we should also reopen that issue since it was a very popular request, and now it has no solution... I wonder if there's some stopgap solution that we can expect to work indefinitely.

If we're saying that this is no longer (tacitly) supported, we should also remove this code:

react/packages/react-reconciler/src/ReactFiberDevToolsHook.new.js

Lines 63 to 68 in ece5295

	if (hook.isDisabled) {
	// This isn't a real property on the hook, but it can be set to opt out
	// of DevTools integration and associated warnings and logs.
	// https://github.com/facebook/react/issues/3877
	return true;
	}

[bvaughn]

I think that specifying some other global boolean (that DevTools and React both could read and respect) feels less fragile than encouraging people to override the hook. In general, I'm wary of any code that overrides the hook.

---

Edit: I don't feel strongly about this. I just think it's hacky and fragile to suggest people disable the warning by overriding the hook. If the response to that is concern that we recommend it on an old GitHub issue, then it seems like we can edit that recommendation.

I'm not opposed to some opt-out mechanism for the warning itself. DevTools doesn't even need to be involved in that. I'm also not opposed to an opt-out mechanism for DevTools integration. I'm just concerned about people overriding or messing with the hook/internal API.

1. It seems fragile since we frequently change the hook without any concern or testing for all of the code in the wild that might be overriding it.
2. If it breaks, people assume React or DevTools are the cause. (This is much less of a concern, but it has wasted our time in the past with digging into issue reports.)

[gaearon]

I think that specifying some other global boolean (that DevTools and React both could read and respect) feels less fragile than encouraging people to override the hook.

👍