-
Notifications
You must be signed in to change notification settings - Fork 47k
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
Ensure lifecycle timers are stopped on errors #7548
Conversation
if (inst.componentDidMount) { | ||
if (__DEV__) { | ||
transaction.getReactMountReady().enqueue(invokeComponentDidMountWithTimer, this); | ||
if (__DEV__ && debugID !== 0) { |
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.
I'm not sure that our www pipeline understands this. I think it's really dumb and only look for if (__DEV__)
as the previous code used two nested ifs
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.
Surprisingly, it does:
$ echo 'if (__DEV__ && debugID !== 0) alert(1);' | jsxmin --replace __DEV__:1
if(debugID!==0)alert(1);
$ echo 'if (__DEV__ && debugID !== 0) alert(1);' | jsxmin --replace __DEV__:0
$
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.
if (¯\_(ツ)_/¯)
Thanks for keeping up with all my questions, this diff looks good to me, here are the things I'd like fixed before accepting it:
|
@@ -86,6 +86,94 @@ describe('ReactDOMProduction', function() { | |||
expect(container.childNodes.length).toBe(0); | |||
}); | |||
|
|||
it('should call lifecycle methods', function() { |
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.
Added this test so we don’t accidentally regress in prod.
This will also fix #6949. |
Looks good as long as this isn't noticeably slower. |
Doesn't seem to be in my testing, extracting try/finally works well (as proven by other libraries like Bluebird). |
In developer mode, I don't see any errors in the console when component render, |
Try/finally blocks can't possibly catch errors. If you don't see errors thrown in your code, this is a problem with your code. For example maybe you are using Promises incorrectly and catch all errors, including errors in your code, and ignore them. This is a common mistake when you call setState() and then use catch() for handing errors. In any case we can't help unless you provide an example reproducing the problem. |
Oh sorry. I thought that try/finally as same as try/catch/finally with empty catch block. Thanks! |
This fixes #7349 and removes a special case for error boundaries that is now unnecessary.
The perf impact on DEV is minimal because
try
/finally
is separated into a function.