ComponentWillUnmount should only ever be invoked once - #6613
Merged
Merged
Conversation
Contributor
Author
Contributor
|
Mostly because we don't have a better idea of whether it is better to just always try/catch or if we can reuse another flag or store where in the tree we left off. |
| this._pendingCallbacks = null; | ||
|
|
||
| // ComponentWillUnmount shall only be called once | ||
| this.calledComponentWillUnmount = false; |
Contributor
There was a problem hiding this comment.
Use underscore for consistency.
jimfb
force-pushed
the
componentWillUnmount-once
branch
from
April 25, 2016 20:30
008058d to
a8e64f1
Compare
|
|
||
| expect(function() { | ||
| ReactDOM.render(<App ref={setRef} />, container); | ||
| stage = 2; |
Contributor
There was a problem hiding this comment.
Any reason not to pass stage as a prop to App?
jimfb
force-pushed
the
componentWillUnmount-once
branch
from
April 26, 2016 00:19
a8e64f1 to
fd43666
Compare
zpao
pushed a commit
that referenced
this pull request
Apr 28, 2016
(cherry picked from commit 8dfdac6)
gaearon
added a commit
that referenced
this pull request
Oct 15, 2016
* Initial pass at the easy case of updates (updates that start at the root). * Don't expect an extra componentWillUnmount call It was fixed in #6613. * Remove duplicate expectations from the test * Fix style issues * Make naming consistent throughout the tests * receiveComponent() does not accept safely argument * Assert that lifecycle and refs fire for error message * Add more tests for mounting * Do not call componentWillMount twice on error boundary * Document more of existing behavior in tests * Do not call componentWillUnmount() when aborting mounting Previously, we would call componentWillUnmount() safely on the tree whenever we abort mounting it. However this is likely risky because the tree was never mounted in the first place. People shouldn't hold resources in componentWillMount() so it's safe to say that we can skip componentWillUnmount() if componentDidMount() was never called. Here, we introduce a new flag. If we abort during mounting, we will not call componentWillUnmount(). However if we abort during an update, it is safe to call componentWillUnmount() because the previous tree has been mounted by now. * Consistently display error messages in tests * Add more logging to tests and remove redundant one * Refactor tests * Split complicated tests into smaller ones * Assert clean unmounting * Add assertions about update hooks * Add more tests to document existing behavior and remove irrelevant details * Verify we can recover from error state * Fix lint * Error in boundary’s componentWillMount should propagate up This test is currently failing. * Move calling componentWillMount() into mountComponent() This removes the unnecessary non-recursive skipLifecycle check. It fixes the previously failing test that verifies that if a boundary throws in its own componentWillMount(), the error will propagate. * Remove extra whitespace
colbyr
pushed a commit
to HubSpot/general-store
that referenced
this pull request
Mar 6, 2017
It seems that in certain versions of React it was possible for `componentWillMount` to be called more than once. react/react#6613 If that happened to a `connect`ed component, it would cause `dispatcher.unregister` to be called again with a token that was already unregistered causing an exception. This `null`s the token field so unregister can only be called once for a given token.
4 tasks
colbyr
pushed a commit
to HubSpot/general-store
that referenced
this pull request
Mar 6, 2017
It seems that in certain versions of React it was possible for `componentWillMount` to be called more than once. react/react#6613 If that happened to a `connect`ed component, it would cause `dispatcher.unregister` to be called again with a token that was already unregistered causing an exception. This `null`s the token field so unregister can only be called once for a given token.
colbyr
added a commit
to HubSpot/general-store
that referenced
this pull request
Mar 6, 2017
It seems that in certain versions of React it was possible for `componentWillMount` to be called more than once. react/react#6613 If that happened to a `connect`ed component, it would cause `dispatcher.unregister` to be called again with a token that was already unregistered causing an exception. This `null`s the token field so unregister can only be called once for a given token.
acusti
pushed a commit
to brandcast/react
that referenced
this pull request
Mar 15, 2017
* Initial pass at the easy case of updates (updates that start at the root). * Don't expect an extra componentWillUnmount call It was fixed in react#6613. * Remove duplicate expectations from the test * Fix style issues * Make naming consistent throughout the tests * receiveComponent() does not accept safely argument * Assert that lifecycle and refs fire for error message * Add more tests for mounting * Do not call componentWillMount twice on error boundary * Document more of existing behavior in tests * Do not call componentWillUnmount() when aborting mounting Previously, we would call componentWillUnmount() safely on the tree whenever we abort mounting it. However this is likely risky because the tree was never mounted in the first place. People shouldn't hold resources in componentWillMount() so it's safe to say that we can skip componentWillUnmount() if componentDidMount() was never called. Here, we introduce a new flag. If we abort during mounting, we will not call componentWillUnmount(). However if we abort during an update, it is safe to call componentWillUnmount() because the previous tree has been mounted by now. * Consistently display error messages in tests * Add more logging to tests and remove redundant one * Refactor tests * Split complicated tests into smaller ones * Assert clean unmounting * Add assertions about update hooks * Add more tests to document existing behavior and remove irrelevant details * Verify we can recover from error state * Fix lint * Error in boundary’s componentWillMount should propagate up This test is currently failing. * Move calling componentWillMount() into mountComponent() This removes the unnecessary non-recursive skipLifecycle check. It fixes the previously failing test that verifies that if a boundary throws in its own componentWillMount(), the error will propagate. * Remove extra whitespace
1 task
mrizwanashiq
pushed a commit
to mrizwanashiq/react
that referenced
this pull request
Jun 25, 2026
mrizwanashiq
pushed a commit
to mrizwanashiq/react
that referenced
this pull request
Jun 25, 2026
* Initial pass at the easy case of updates (updates that start at the root). * Don't expect an extra componentWillUnmount call It was fixed in react#6613. * Remove duplicate expectations from the test * Fix style issues * Make naming consistent throughout the tests * receiveComponent() does not accept safely argument * Assert that lifecycle and refs fire for error message * Add more tests for mounting * Do not call componentWillMount twice on error boundary * Document more of existing behavior in tests * Do not call componentWillUnmount() when aborting mounting Previously, we would call componentWillUnmount() safely on the tree whenever we abort mounting it. However this is likely risky because the tree was never mounted in the first place. People shouldn't hold resources in componentWillMount() so it's safe to say that we can skip componentWillUnmount() if componentDidMount() was never called. Here, we introduce a new flag. If we abort during mounting, we will not call componentWillUnmount(). However if we abort during an update, it is safe to call componentWillUnmount() because the previous tree has been mounted by now. * Consistently display error messages in tests * Add more logging to tests and remove redundant one * Refactor tests * Split complicated tests into smaller ones * Assert clean unmounting * Add assertions about update hooks * Add more tests to document existing behavior and remove irrelevant details * Verify we can recover from error state * Fix lint * Error in boundary’s componentWillMount should propagate up This test is currently failing. * Move calling componentWillMount() into mountComponent() This removes the unnecessary non-recursive skipLifecycle check. It fixes the previously failing test that verifies that if a boundary throws in its own componentWillMount(), the error will propagate. * Remove extra whitespace
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
ComponentWillUnmount should only ever be invoked once