Replace React.error and React.warn with getComponentStack

[bvaughn]

Proposed alternative to #15170

Several people have asked, "Could you provide a method to access the component stack directly?". I think our reasoning against this was that we didn't want people to depend on that stack, or to try to parse it and build anything on top of it.

I don't think we considered the case of instrumenting error logging though. Facebook (and probably others) overrides console.error to capture the call stack and save it somewhere. A downside of React.error is that it would cause errors from different call sites to be grouped together (unless the instrumenting code was smart enough to skip over the React frame).

Overriding only these two console methods also feels like a bit of an incomplete solution (#15726) to the logging story.

This PR replaces React.warn and React.error with a method that returns the current component stack¹ which people can log to whichever console group they want.

¹ At the moment, this method always returns an empty string in prod.

[bvaughn]

Should this not return anything? Seemed weird to return void/undefined in prod and an empty string when called outside of the render phase in DEV, so I opted to return empty string in both cases for now.

[sizebot]

React: size: 🔺+0.1%, gzip: -0.1%

Details of bundled changes.

Comparing: eb2ace1...cd2fc91

react

File	Filesize Diff	Gzip Diff	Prev Size	Current Size	Prev Gzip	Current Gzip	ENV
react.development.js	-0.6%	-0.4%	112.54 KB	111.89 KB	28.51 KB	28.38 KB	UMD_DEV
react.production.min.js	🔺+0.1%	-0.1%	13.15 KB	13.16 KB	5.07 KB	5.06 KB	UMD_PROD
react.profiling.min.js	0.0%	-0.1%	15.34 KB	15.35 KB	5.63 KB	5.63 KB	UMD_PROFILING
react.development.js	-0.9%	-0.6%	71.36 KB	70.72 KB	18.63 KB	18.53 KB	NODE_DEV
react.production.min.js	🔺+0.1%	-0.1%	6.69 KB	6.7 KB	2.75 KB	2.75 KB	NODE_PROD
React-dev.js	-0.9%	-0.6%	69.57 KB	68.93 KB	17.89 KB	17.79 KB	FB_WWW_DEV
React-prod.js	🔺+2.3%	🔺+0.7%	16.86 KB	17.24 KB	4.43 KB	4.46 KB	FB_WWW_PROD
React-profiling.js	+2.3%	+0.7%	16.86 KB	17.24 KB	4.43 KB	4.46 KB	FB_WWW_PROFILING

Generated by 🚫 dangerJS

[sebmarkbage]

It’s not just about the component stack but other things we can do with it like reorder and delay etc.

This doesn’t address the abuse problem. The reason this wasn’t earlier is because there were many really bad use cases people were intending to use this for.

[bvaughn]

It’s not just about the component stack but other things we can do with it like reorder and delay etc.

That sounds more like a broader logging strategy which we still need to decide on (#15726). I see that as separate from the more focused need of accessing a component stack. Do you disagree?

This doesn’t address the abuse problem. The reason this wasn’t earlier is because there were many really bad use cases people were intending to use this for.

TBH bad actors would probably misuse e.g. React.warn as well by intercepting calls to console.warn. I think we can only advocate for not doing that. On the other hand, the current approach (from #15170) doesn't account for existing error logging/aggregating use cases, which is the main reason I opened this PR in the first place...

[bvaughn]

Sebastian and I had a productive conversation this afternoon regarding my concerns above.

The quick takeaway is this: I will be updating this PR to remove React.warn and React.error without adding an additional getComponentStack method. We can revisit these methods later as part of a larger discussion around the console logging experience with React (see #15726) but we should not block 16.9 for this.

In the meanwhile, I will be adding functionality to React DevTools to intercept calls to console.error, console.warn, and console.trace and auto-append component stacks (in DEV mode). This seems like a nice 80/20 solution that doesn't limit our options for a future API.

Might also be worth looking into a log view within DevTools that groups and orders logs by commit, etc.

[bvaughn]

Closing in favor of #16126