-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
React team has removed the warning on setting setState
on an unmounted component
#148
Comments
IMHO the are actual (but insignificantly small) memory leaks were/are real, but the bigger problem was that 99.9% of workarounds to get rid of the warning (including the the pattern can be still useful to have in our tool belts, but no idea what is the best scenario to explain it if if (isMounted) {
doSomethingThatMakesSenseOnlyIfMounted()
} |
...maybe starting some imperative animation for "payment confirmed" after 200 response from a POST request, that would only make sense if still mounted and perhaps a counter-example to remove some imperative DOM event listeners - those should always be in the cleanup of a useEffect without any guarding, event listeners have to be removed unconditionally, especially if React is unmounting / already unmounted 😅 |
Thanks @payapula! I'll be removing this from the workshop in the future :) |
In your workshop material you mentioned "Also notice that while what we're doing here is still useful and you'll learn valuable skills" React.useEffect(() => { return React.useCallback( But As mentioned on the link reactwg/react-18#82 In the future, we'd like to offer a feature that lets you preserve DOM and state even when the component is not visible, but disconnect its effects. With this feature, the code above doesn't work well. You'll "miss" the setPending(false) call because isMountedRef.current is false while the component is in a hidden tab. So once you return to the hidden tab and make it visible again, it will look as if your mutation hasn't "come through". By trying to evade the warning, we've made the behavior worse. In addition, we've seen that this warning pushes people towards moving mutations (like POST) into effects just because effects offer an easy way to "ignore" something using the cleanup function and a flag. However, this also usually makes the code worse. The user action is associated with a particular event — not with the component being displayed — and so moving this code into effect introduces extra fragility. Such as the risk of the effect re-firing when some related data changes. So the warning against a problematic pattern ends up pushing people towards more problematic patterns though the original code was actually fine." Please tell what should we do? |
Don't worry about it unless it becomes a problem in your app (it probably won't). |
Hi @kentcdodds
I just noticed this today that react team removed the warning on setState on unmounted components - facebook/react#22114
In the workshop material, (Exercise: 02, Extra credit 03) we may need to highlight this and give a link to this pull request Remove the warning for setState on unmounted components as it claims these are not really memory leak.
Just opening this here as a feedback.
The text was updated successfully, but these errors were encountered: