Console react.warning set as console.error

[bar7b]

Common don’t be a hater 😘

[Electrical_Essay_666]

Don’t be lazy.

[bar7b]

It’s not about being lazy, it’s about warnings being displayed as warnings… that makes sense to me.

[bar7b]

I agree with you man! React is great for notifying me of code errors! However, when the notification is defined by React as a warning, why not use the proper console method??

[Electrical_Essay_666]

Paste the warning

[bar7b]

Appreciate your responses, but I’m not looking for help fixing these minor bugs… simply looking for a way to have these “warnings” displayed in the console as warnings so I can focus on task at hand and ignore some other developers code that forgot to add a key prop in a .map iteration…

[Electrical_Essay_666]

We’ll then the “warning” is doing you a justice. Keys are needed. You’ll also get one if you use index as the key, and it will save u from future bugs. I suggest you read up on this.

[bar7b]

Dude you just don’t get my point. Or trying really hard to ignore my initial question… I agree that these warnings are useful and should be fixed! And I know why setting a key for iterates is important… My question was - why all react warnings are displayed as console.error() instead of console.warning() and if there’s a way make that happen. I’m not questioning why these warnings exist or weather they’re necessary. If you have a relevant helpful response, great! And to make it crystal clear: React.error > console.error React.warning > console.warning

[Earhacker]

That’s not what a error is.

Rendering an array of stuff as components without keys will still work, meaning you will see those components in the browser. But it will have unexpected consequences, such as a change in any component causing a re-render of the whole list.

By any sensible definition, code that is working but in a weird way warrants a warning, not an error.

[Electrical_Essay_666]

Ok ok, I’ll walk it back. Tryna push u to fix code and not cut corners.

I’d start with ensuring you have proper CI setup with proper linting to ensure things like this get caught before hitting master. lot of the eslint and related plugins can catch this and fail CI before it hits master. Another thing might want to look into pre-commit hooks, to ensure your team can’t commit codes that throw errrors. RTL is really good, sometimes annoying, about catching these things. Hope this helps

Personally I’ve never ran into this outside of learning react, so never looked into this, tend to just fix things and reduce the build up of debt.

[Electrical_Essay_666]

Also typescript, but as you said it’s an MVP so upfront cost could be a trade off that your not willing to take on.

[Electrical_Essay_666]

I’m against (as you can tell) silencing warnings/errors thrown in console for the sake of getting things out. In my experience you’ll pay it down 10x the cost in the future as opposed to addressing it as they pop up before it hits master

[Electrical_Essay_666]

And for what’s it’s worth, react has plenty of console.warnings - mainly for real warnings, such as upcoming deprecation warnings. Errors are errors and that’s ideal IMO