Improve the warning strategy

[eps1lon]

How do you guys want to handle the warning thing in the future, there is a wide range of different options. There are two problems with a strategy like this:

https://github.com/mui-org/material-ui/blob/8ae684d7c9d884c84d89c40da88b46254e5d53a2/packages/material-ui/src/RadioGroup/RadioGroup.js#L39-L52

• We have extra code that is not removed in production.
• We raise more warnings in the console than necessary. It's creating noise.

Maybe?

import React from 'react';

/* to package into it's own module */
const dedup = {};
function warning(message, type) {
  if (!dedup[type]) {
    React.warn(messasge);
    dedup[type] = 1;
  }
}

function MyComponent() {
  if (foo === bar) {
    warning('No, you should not bazzz', 'MyComponent');.
  }
}

plus https://github.com/oliviertassinari/babel-plugin-transform-dev-warning

Another option:

import React from 'react';

/* to package into it's own module */
const dedup = new WeakMap();
function warning(condition, message) {
  const { current } = React.useRef({});
  if (!condition && !dedup.has(current)) {
    React.warn(messasge);
    dedup.set(current);
  }
}

function MyComponent() {
  warning(foo !== bar, 'No, you should not bazzz');.
}

Originally posted by @oliviertassinari in #15291 (comment)

[oliviertassinari]

• React will soon release a new warning API that logs the component stack trace.
• After the discussion in Turn deprecation warnings into logs #15397 with @fzaninotto. We probably want to use React.warn() over React.error(). We should use the correct log level.
• We should be able to remove the warning dependency :)

[oliviertassinari]

React has reverted the warn and error helpers: facebook/react#16126.

[eps1lon]

I'm going to evaluate our custom propTypes and see what we can move into custom console.warn and console.error. The new react devtools should append the component stack to those now.

[oliviertassinari]

Sweet, from what @merceyz said, it could unlock the migration of more components to the props description in the TypeScript defintions :).

[eps1lon]

Referencing #17480 here. It's probably good to have some link/section about debugging react apps. The error overlay for create-react-app prioritizes the JS stack trace and has a barely legibly notice about console. We need to make sure devs are aware that they need to read (and address) the console output top-down not bottom-up .

[oliviertassinari]

@eps1lon Since #17404 was merged, what do we miss to close the issue?

[eps1lon]

@eps1lon Since #17404 was merged, what do we miss to close the issue?

Go through current console.error and decide if console.warn would be sufficient.

[oliviertassinari]

Looking at the codebase, I can count:

• console.error x68
• console.warn x7

What do you think of reserving the usage of console.error to the cases where the page actually crashes? console.warn is used as soon as something is not right, leading to incorrect behavior.

[eps1lon]

Closing this for now unless React.warn gets re-introduced.

[oliviertassinari]

Did you decide on a policy around console.warn vs console.error (when to use which one)? #15343 (comment)