New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Disable prepareStackTrace while we're generating stacks #18708
Conversation
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit 8d56927:
|
@bvaughn Should we port this to DevTools too? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok but I think DEV condition is mismatching
@@ -182,6 +185,7 @@ export function describeNativeComponentFrame( | |||
reentry = false; | |||
if (__DEV__) { | |||
ReactCurrentDispatcher.current = previousDispatcher; | |||
Error.prepareStackTrace = previousPrepareStackTrace; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you mean to put this outside of DEV?
Yeah seems worth adding.
I'm not sure I understand this suggestion? We don't have enough info in the string (and so a custom parser wouldn't have enough info) to fully reconstruct a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks fine except for the mismatched DEV
conditional.
This could be used to do custom formatting of the stack trace in a way that isn't compatible with how we use it. So we disable it while we use it. In theory we could call this ourselves with the result of our stack. It would be a lot of extra production code though. My personal opinion is that this should always be done server side instead of on the client. We could expose a custom parser that converts it and passes it through prepareStackTrace as structured data. That way it's external and doesn't have to be built-in to React.
c8028d6
to
8d56927
Compare
The root cause was facebook/react#18708 temporarily doing `Error.prepareStackTrace = undefined` to get a stack string. This wasn't handled correctly by error-callsites (watson/error-callsites#3). Fixes: #1980
…7+ (#2107) The root cause was facebook/react#18708 temporarily doing `Error.prepareStackTrace = undefined` to get a stack string. This wasn't handled correctly by error-callsites (watson/error-callsites#3). Fixes: #1980
…7+ (elastic#2107) The root cause was facebook/react#18708 temporarily doing `Error.prepareStackTrace = undefined` to get a stack string. This wasn't handled correctly by error-callsites (watson/error-callsites#3). Fixes: elastic#1980
This could be used to do custom formatting of the stack trace in a way that isn't compatible with how we use it. So we disable it while we use it.
In theory we could call this ourselves with the result of our stack. It would be a lot of extra production code though. My personal opinion is that this should always be done server side instead of on the client. This is not infrastructure that is worth its code size.
We could expose a custom parser that converts it and passes it through prepareStackTrace as structured data. That way it's external and doesn't have to be built-in to React.