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.

👍

[bearow]

I'd like to take it, if it's possible.

[gaearon]

Sure!

[bearow]

just an fyi that this issue is not forgotten, I'll look at it this/next week, got sick just after I said I want to take it :-/

[tjx666]

any progress?

[bearow]

https://github.com/bearow/react/tree/suppress-devtools-logs-flag

I'm not sure if I did it as you guys imagined it. Also I'm currently struggling a little with testing it manually to check if it works as intended.
@tjx666 You can of course try it out yourself if you want.

Sorry for the slow progress.

(when I test it out I'll rebase and create a PR)

[Steve-Nguyen]

Having an official method to remove the ad is better than having people hack together a fix that may have unintended consequences. Looking forward for updates on this!

[JuniorTour]

hi, @bearow , It has been more than 10 weeks since you take this issue.

If you don't mind, I would like to make a Pull Request to fix this issue.

[bearow]

@JuniorTour sure, go ahead - I got overwhelmed by life :-/

[felixcatto]

It is incredible that we can't disable this nasty message 😢
If i use new webpack.DefinePlugin({ __REACT_DEVTOOLS_GLOBAL_HOOK__: '({ isDisabled: true })' }) in next js, it completely disables HMR. Seems the only solution is to go and delete this console.log in node_modules react source code 😕

[silverwind]

One can proxy console.info and filter the message. Just needs to be done early enough, like in an inline script in HTML.

  try {
    console.info = new Proxy(console.info, {
      apply: (target, thisArg, args) => {
        if (args?.[0]?.includes?.("React DevTools")) return;
        return Reflect.apply(target, thisArg, args);
      },
    });
  } catch {}

Would strongly suggest react to just drop this silly advertisement.

[kaiyoma]

Any updates here? I see this annoying message when running unit tests and it makes the output unnecessarily noisy. Example:

 RERUN  ../modules/provisioning/components/QuickReconcileButton/__test__/index.spec.tsx x1

stdout | unknown test
Download the React DevTools for a better development experience: https://reactjs.org/link/react-devtools

stdout | unknown test
Download the React DevTools for a better development experience: https://reactjs.org/link/react-devtools

stdout | unknown test

[lotyp]

I can confirm @kaiyoma issue, warning is thrown when running vitest application

[anthonyblond]

I noticed this in vitest, after upgrading from v0.34.1 to v0.34.2.

I also noticed it happens when using happy-dom as the environment, not jsdom. So I think it may be something to do with "Pass environmentOptions to happy-dom integration" mentioned in the v0.34.2 release notes.

As a temporary workaround I'm using jsdom instead of happy-dom, but that is because I was having another issue with happy-dom. Another alternative would be to ensure vitest is locked to version 0.34.1 and no higher.

[capricorn86]

I noticed this in vitest, after upgrading from v0.34.1 to v0.34.2.

I also noticed it happens when using happy-dom as the environment, not jsdom. So I think it may be something to do with "Pass environmentOptions to happy-dom integration" mentioned in the v0.34.2 release notes.

As a temporary workaround I'm using jsdom instead of happy-dom, but that is because I was having another issue with happy-dom. Another alternative would be to ensure vitest is locked to version 0.34.1 and no higher.

I'm not sure why it started to happen in that particular release, but the reason for why you get this error message in Happy DOM is because of this check in React:

if (
      (navigator.userAgent.indexOf('Chrome') > -1 &&
        navigator.userAgent.indexOf('Edge') === -1) ||
      navigator.userAgent.indexOf('Firefox') > -1
    )

It matches the default user agent in Happy DOM, but not in JSDOM.

As a temporary fix you can use Object.defineProperty(global.navigator, 'userAgent', { value: 'happy-dom', writable: false }).

[capricorn86]

This has now been fixed in Happy DOM v12. Happy DOM will no longer be detected as a supported browser when using the default user agent.