I still absolutely hate this system. At least we finally get some form of non minified exceptions at runtime but surely in the grand scheme of things those messages can't add that much overhead.
It's 4.5KB gzipped. All things considered this is insignificant to a normal react app.
This just adds extra overhead for everybody who tries to deal with those react errors in production (like for instance Sentry).
From @benvinegar's comments there (ex: https://github.com/facebook/react/issues/2686#issuecomment-2...) it sounded like the error code system would go at least most of the way towards solving your problem. Obviously the error message would not show up in Sentry automatically, but I figured that it would be a click away. I guess I must have misunderstood something along the line though.
It's a huge step up and I'm grateful, not only because this will be a huge improvement for Sentry users (and other crash reporting service users), but also because we use React ourselves. Thanks React team.
People obsess about single kilobytes of JavaScript because it's easy to measure, not because it makes a difference to web performance. (It doesn't, in the vast, vast majority of cases.) It is not worth adding even a little bit of complexity to strip these debug messages from minified code.
I am grateful to developers making sites lightweight that load on my 2G connection in a village in Serbia with a 150MB monthly data cap. I'd like to use Opera Mini more but it breaks many websites so I use Firefox and hope for the best.
But React is just the view layer. If you add weight to every script, you could add 100K of extra stuff that is not essential in production. This may not seem important, but page weight/JS size absolutely makes a huge difference in many parts of the world and on slower devices.
It's 4.5KB gzipped. All things considered this is insignificant to a normal react app.
This just adds extra overhead for everybody who tries to deal with those react errors in production (like for instance Sentry).