Use warn instead of error for warnings

[sean-clayton]

console.warn is both visually and semantically correct for displaying warnings than console.error. I recommend switching to it 👍

[facebook-github-bot]

Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla - and if you have received this in error or have any questions, please drop us a line at [email protected]. Thanks!

[facebook-github-bot]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks!

[zpao]

Thanks but we're not going to take this. We intentionally changed to using console.error to improve the debugging experience, namely that you get native logging of stack traces.

[sean-clayton]

@zpao Why not use console.trace() in conjunction?

[sophiebits]

console.trace would probably be okay, though the yellow/red background is something we also want to keep. We also generally only use warning() for "must-fix" warnings where you really should fix them, so I don't mind the harshness of console.error. At Facebook internally we use an alert()-like modal dialog for all warnings to ensure they're seen.

[SimplyLinn]

I have to agree with @sean-clayton on this. The facebook way of seeing warnings as more severe and display them as errors is really taxing on people used with the notion that "Big red bad error means the execution in a task has halted and not completed" while a warning means "Something went wrong during execution, but it did not necessarily halt."

Using big red messages saying "THE PROGRAM HAS HALTED AT THIS LINE PANIC!" when all you really mean is "You have a rather severe problem on line X, I can work around it, but fix it." goes against what both the browsers themselves are outputting into the console (errors for failed HTTP-requests, warnings when stuff do not have the correct content-type header, but the correct content-type header can be deduced etc.)

Not conforming to this de-facto standard within the JS community means you're in a sense isolating you're possibly hiding important fatal errors among your warnings, making debugging harder than it usually is. When I'm trying to fix a fatal error, I want the warning to be a warning, and the fatal error to be a fatal error. Warnings and errors are not equal!

A compromise would be to use non-fatal errors and call them that, errors if that's what you mean. But seeing "Warning: " in a console.error-log is just a contradiction.

[mellis481]

@zpao How does using console.error in a function called warning() and where the message being logged starts with "Warning:" not make you feel like you're doing something wrong/hacky?

[nukeop]

React screams in mile-long red errors about the most trivial things, like extra unrecognized props. Every single project I've ever seen barfs dozens upon dozens of such errors whenever you open the console. The first thing I do is patch this out. I might be missing some useful logs, but I'm not the one crying wolf.

[sophiebits]

The React team uses console.error() for issues that should be fixed. The main reason they're not throwing errors is that the validation is too expensive to do in production, otherwise they would be. Since it's only done in development we don't want to throw (in order to ensure that dev and prod have the same behavior) but conceptually they are errors and typically occur when triggering unsupported behavior in React. I agree that many projects often have a handful of these warnings checked into the code but the solution is not to make them quieter. I would rather make them louder to reduce the chance of them getting checked in in the first place.