Introducing React's Error Code System | Hacker News Reader

Introducing React's Error Code System

facebook.github.io

129 pointsclessg44 comments

> Minified React error #109; visit https://facebook.github.io/react/docs/error-decoder.html?inv... for the full message or use the non-minified dev environment for full errors and additional helpful warnings.

While this looks useful, if `Foo` is an part of my application state I'm not too crazy about shipping that over to Facebook if I wanted to use this feature.

Thanks, this is a concern we didn't consider.

To clarify: the error message contains a link which goes to our GitHub pages site -- nothing is sent to any server automatically. You can always edit the URL if there's sensitive data in it for some reason.

You can also review the full source of our site or run it locally if you care to; it's all in the repo.

It still means I'm sending potentially sensitive data (idk, passwords) to a server I don't own. There is no way I can trust github on this. Would there be a less-than-hacky way then regexing the URL? a way to let it redirect to a self-hosted version of the github page for example? Shouldn't be too hard to add and would solve OPs concerns.

The `reactProdInvariant` function [1] does the URL encoding job and the decoder on our documentation page is just a React component [2]. I totally understand your concern and for now you can simply edit the `reactProdInvariant` function to fit your needs.

[1] https://github.com/facebook/react/blob/master/src/shared/uti...

[2] https://github.com/facebook/react/blob/master/docs/_js/Error...

> It still means I'm sending potentially sensitive data (idk, passwords) to a server I don't own

Not sure if you missed spicyj's point or arguing that you yourself might not notice the sensitive data in the url.

If you - as the developer - need to inquire more about the error (say after reproducing it on production), you copy and paste the error url and remove the sensitive data before going to said url.

What about using the hash part of the URL (#) instead of the query part (?)? That doesn't get sent to the server. Although you still have to trust that a script on the page isn't reading that information and shuttling it off somewhere else--but then, you're already trusting Facebook code anyway.

Suggestion: you can provide some UI on the site to copy paste the error message instead of linking.

Even copying the error can be made a bit easier. Most (atleast FF and Chrome) consoles have the `copy` function which directly copies the passed string to clipboard. So when the error occurs, you can store it in an object in the global scope and the developer can just copy it with `copy(React.runtimeErrors.<errid>)` which is all autocompleted by the console anyways.

Now surely copy pasting secret stuff on another site is not very secure, but atleast it is not gonna be leaked to everyone in between the network from the url.

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).

Sorry to hear this. When we spend effort stripping out bytes some people complain; when we leave it alone, others complain about the size.

We thought this was a good compromise, but maybe we'll revisit in the future. Your feedback is valuable.

For what it's worth we have been vocal on the issue tracker about this for a long time: https://github.com/facebook/react/issues/2686

I know.

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.

Some people will just never stop complaining. Thanks for your great work.

We automatically resolve your error codes now. We just wish this was at least a standard like sourcemaps.

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.

If you serve to mobile phones in third world countries every KB counts. For some of us this is a reality.

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.

Then maybe "if you serve to mobile phones in third world countries" don't use React?

Facebook serves to mobile phones in third world countries.

In what way does this invalidate what I wrote, which, if I have to make it even plainer, is:

If you're serving to mobile phones in third world countries [and you're concerned with React's size], then you can always NOT use React.

Apparently Facebook is not concerned with that, or doesn't consider it a problem for third world networks.

But for those people that complain about React's size and third world usage, they do know that there are tons of lighterweight options, right?

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.

Sort of off-topic but interesting: This post and code (guessing) was made by a young intern[1] who has received praise from the likes of Dan Abramov more than a few times for core contributions to React.

Hoping to see more awesome stuff from him!

[1] http://keyanzhang.com/

One of the many nice things about React that I enjoyed when switching from Angular and Backbone was the super helpful error messaging. Now they go and make it even better. Nice work, React team!

Angular 1 had, on the face of it, a nearly identical error message mechanism/website. It was annoying as hell and rarely useful. Maybe React will have better execution.

Curious: what made it annoying and rarely useful? We'd like to avoid the same mistakes if possible.

Speaking for us (Sentry) it's utterly frustrating that we now have to add framework specific code in so that error handling works again for customers. I think the number one complaint was minified exceptions over the last year where we just encouraged people to not run with the production environment. This is clearly a step to something where customers can be satisfied but the cost is that we now scrape your codes.json and add custom handling just for React.

It's a terrible precedent and lacks any sort of standard :-/ I'm not a fan of this sort of pattern spreading.

If it spread to a become a defacto standard format, wouldn't that be a good thing? That way you only have to deal with this once and it will work everywhere.

At that time, the size/parse time will have much greater impact because the total size of libraries will be smaller or unaffected.

At the same time it encourages libraries to put significant error messages in their code without fear of bloat which helps your customers in the end.

Personally, I hope everyone will follow.

Since the URL to the raw mapping is not in the error and requires external knowledge and the parameters are in free form in the error message I doubt this can become a standard of any sorts. The correct place for this would have been something like sourcemaps.

Yea, this is clearly not enough to be a standard but we don't really know of a standard for this and it is not really our primary expertise.

If Sentry or others that understand this problem space better create a standard format, we would be happy to switch to that.

Everything have to start somewhere. :)

For me, most of the time, the URLs it encoded didn't actually work if you put them back into the browser. Not sure if they were too long (they were really really long, seemed to encode stack information).

Edit: here's someone complaining about it: https://github.com/angular/angular.js/issues/6077

How much does does this save? Is it really worth the complexity?

Parse time is the new bottleneck of modern client-side web apps. Of course React on its own isn't going to move the needle but if other libraries follow along it just might. With better, more expressive error messages without paying the cost at scale.

If you can show me even a contrived example of a React app where the presence or absence of three kilobytes of debug messages makes a measurable difference to performance, I will be very impressed (and humbled).

To me its not about the 3KB, thats negligible. Its more the precedent.

It is a strong statement that React cares strongly about my page weight, even as small as 3KB. At least the implied message it sends me:

1. I really should care about my page weight too.

2. React must really need every KB it currently uses. And if not, it will soon optimize away the bloat.

I'm not so sure I agree there. Not that React isn't fantastic, but I remember a recent release adding support for SVG elements. If I don't use any, it would be great to strip out that functionality - React is not a small library. Alternatives like Preact show that you can have a core set of functionality at a much smaller size.

With the prevalence of npm and mini-libraries I'd be interested to see if the size of React could be cut down and put into optional components.

Have there been any efforts to have tree shaking work with react?

It's not a magic bullet, but it can go a long way in helping remove a ton of unused-for-your-use-case code in your production build.

I don't think tree shaking would help much. Speaking as an author of one of those mini-virtual-dom libraries, from my experience/research, the choices of features to support are usually tightly integrated for performance reasons.

For tree shaking to work, it must be possible to statically infer that some code is not part of the dependency graph of your application. Something like SVG support requires extensions to the virtual dom node structure that the renderer's visitor looks at, so it's quite difficult to make it into a hook and not lose performance to various overheads. It's also worth mentioning that over-modularizing can get boilerplatey (e.g. https://github.com/paldepind/snabbdom#inline-example)

Saving a handful of kb on a JS library quickly gets shot to hell when you have to load up sixteen analytics trackers, an auto-playing video, and a bevy of unoptimized ad images.

There is lower-hanging, bigger-buck-for-your-bang, fruit if you're trying to fight page bloat.

And React can't prevent any of those. React can only change React code, so they optimize it as best as they can, and leave the "user" of React to optimize everything else in their own app.

This saves ~3KB gzipped (comparing to having all original error messages bundled in).

Will the codes.json [1] never reorder indicies? Looking at the gulpfile it seems they could as React changes? So maybe need a version system for codes.json.. Not sure; seems handy anyway.

[1] - https://github.com/facebook/react/blob/master/scripts/error-...

Yes to make that reliable the indices may never change and even if an error is no longer used it must still be in the map. Looking at the gulp script I would say it guarantees that, because it takes the old errorcode file as a starting point for generating a new one.

Another requirement would be that the URL on the server also does not change, otherwise the links from older react version would be broken.

This is awesome! Was just wondering about something like this recently after installing bugsnag. Off topic, but what are everyone's thoughts on bugsnag vs sentry or other similar systems?

This could mean good things for localization as well. :-)

Reply on news.ycombinator.com