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