
Introducing React's Error Code System - clessg
https://facebook.github.io/react/blog/2016/07/11/introducing-reacts-error-code-system.html
======
zerovox
> Minified React error #109; visit
> [https://facebook.github.io/react/docs/error-
> decoder.html?inv...](https://facebook.github.io/react/docs/error-
> decoder.html?invariant=109&args\[\]=Foo) 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.

~~~
spicyj
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.

~~~
arianvanp
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.

~~~
keyanzhang
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...](https://github.com/facebook/react/blob/master/src/shared/utils/reactProdInvariant.js)

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

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

~~~
spicyj
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.

~~~
the_mitsuhiko
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](https://github.com/facebook/react/issues/2686)

~~~
spicyj
I know.

From @benvinegar's comments there (ex:
[https://github.com/facebook/react/issues/2686#issuecomment-2...](https://github.com/facebook/react/issues/2686#issuecomment-217990488))
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.

~~~
bentlegen
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.

------
sotojuan
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/](http://keyanzhang.com/)

------
oaxacaoaxaca
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!

~~~
regecks
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.

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

~~~
the_mitsuhiko
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.

~~~
sebmarkbage
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.

~~~
the_mitsuhiko
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.

~~~
sebmarkbage
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. :)

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

~~~
sebmarkbage
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.

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

~~~
yazaddaruvala
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.

~~~
untog
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.

~~~
Klathmon
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.

~~~
lhorie
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](https://github.com/paldepind/snabbdom#inline-example))

------
nthitz
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-...](https://github.com/facebook/react/blob/master/scripts/error-
codes/codes.json)

~~~
Matthias247
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.

------
lcarlson
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?

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

