5 ms·

Introducing React's Error Code System

129 points by clessg 10y ago

microcolonel 10y ago
This could mean good things for localization as well. :-)
sotojuan 10y ago
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 10y ago
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 10y ago
  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 10y ago
    Curious: what made it annoying and rarely useful? We'd like to avoid the same mistakes if possible.
    - the_mitsuhiko 10y ago
      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 10y ago
        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 10y ago
        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 10y ago
        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. :)
    - regecks 10y ago
      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 https://github.com/angular/angular.js/issues/6077
    - deleted 10y ago
      [deleted]
zerovox 10y ago
> Minified React error #109; visit https://facebook.github.io/react/docs/error-decoder.html?invariant=109&args[]=Foo 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.
- spicyj 10y ago
  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 10y ago
    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 10y ago
      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/utils/reactProdInvariant.js https://github.com/facebook/react/blob/master/src/shared/uti... [2] https://github.com/facebook/react/blob/master/docs/_js/ErrorDecoderComponent.js https://github.com/facebook/react/blob/master/docs/_js/Error...
    - mintplant 10y ago
      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.
brandonbloom 10y ago
How much does does this save? Is it really worth the complexity?
- sebmarkbage 10y ago
  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 10y ago
    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 10y ago
      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 10y ago
        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.
        10y ago
the_mitsuhiko 10y ago
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 10y ago
  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 10y ago
    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 10y ago
      I know. From @benvinegar's comments there (ex: https://github.com/facebook/react/issues/2686#issuecomment-217990488 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.
      - the_mitsuhiko 10y ago
        We automatically resolve your error codes now. We just wish this was at least a standard like sourcemaps.
      - bentlegen 10y ago
nthitz 10y ago
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-codes/codes.json https://github.com/facebook/react/blob/master/scripts/error-...
- Matthias247 10y ago
  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 10y ago
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?

129 points by clessg 10y ago

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

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 10y ago

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 10y ago
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 10y ago
  Curious: what made it annoying and rarely useful? We'd like to avoid the same mistakes if possible.
  - the_mitsuhiko 10y ago
    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 10y ago
      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 10y ago
        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 10y ago
        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. :)
  - regecks 10y ago
    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 https://github.com/angular/angular.js/issues/6077
  - deleted 10y ago
    [deleted]

zerovox 10y ago

> Minified React error #109; visit https://facebook.github.io/react/docs/error-decoder.html?invariant=109&args[]=Foo 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.

spicyj 10y ago
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 10y ago
  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 10y ago
    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/utils/reactProdInvariant.js https://github.com/facebook/react/blob/master/src/shared/uti... [2] https://github.com/facebook/react/blob/master/docs/_js/ErrorDecoderComponent.js https://github.com/facebook/react/blob/master/docs/_js/Error...
  - mintplant 10y ago
    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.

brandonbloom 10y ago

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

sebmarkbage 10y ago
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 10y ago
  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 10y ago
    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 10y ago
      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.
      - 10y ago

the_mitsuhiko 10y ago

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 10y ago
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 10y ago
  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 10y ago
    I know. From @benvinegar's comments there (ex: https://github.com/facebook/react/issues/2686#issuecomment-217990488 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.
    - the_mitsuhiko 10y ago
      We automatically resolve your error codes now. We just wish this was at least a standard like sourcemaps.
    - bentlegen 10y ago

nthitz 10y ago

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

Matthias247 10y ago
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 10y ago

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?