[all components][RFC] Refine logging strategy
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 99.1k
- Forks
- 32.5k
- Avg merge
- 2d 17h
- Merged PRs (30d)
- 106
Description
Context
This is a follow-up on #15343. Looking at the components (under /packages/*), we can count the following usage frequency of the different logging methods:
console.error()x69console.warn()x25
Historically, React used to use console.warn(). It was changed in https://github.com/facebook/react/pull/3440 to benefit from the stack trace of console.error(). But fast forward to 2020, Chrome dev tools now support stack trace for console.warn() too. Proof:
Problem
It doesn't seem that there is any rule or convention around when to use error over warn. Do we have an improvement opportunity here? Could we use it as leverage to help developers that need to prioritize which problem they should focus on first?
Proposal
What do you think of:
- If we are unsure, better say it's an
erroroverwarnto be safe. console.errorwe use it for cases that are important. It can be a crash of the page, explaining what went wrong, or creating awareness about a significantly wrong user-experience. For instance:
https://github.com/mui/material-ui/blob/56a1141631905f65c1f5c1d5f41702016327a4ad/packages/material-ui/src/FormControl/FormControl.js#L135-L140console.warnis used as soon as something is not right, leading to incorrect behavior but not critical. For instance, these should be warnings:
https://github.com/mui/material-ui/blob/56a1141631905f65c1f5c1d5f41702016327a4ad/packages/material-ui/src/StepContent/StepContent.js#L44-L46
https://github.com/mui/material-ui/blob/56a1141631905f65c1f5c1d5f41702016327a4ad/packages/material-ui-icons/src/Motorcycle.js#L4-L8
https://github.com/mui/material-ui/blob/56a1141631905f65c1f5c1d5f41702016327a4ad/packages/material-ui/src/Breadcrumbs/Breadcrumbs.js#L81-L86
https://github.com/mui/material-ui/blob/56a1141631905f65c1f5c1d5f41702016327a4ad/packages/material-ui/src/GridList/GridList.js#L46-L50
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by auditing the console.error() and console.warn() usages under /packages/* against the proposed severity guidelines and referenced examples. Done would be an agreed logging convention and a concrete, reviewed plan for applying it across components; the issue names no target file or test.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript, react
- Domain
- frontend
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100