React DevTools might retain references to unmounted DOM elements (and their Fibers)
See original GitHub issue
There’s seems to be circumstances where unmounted DOM/Fibers are kept alive by React DevTools. They’re kept alive in
primaryFibers
:
https://github.com/facebook/react/blob/34527063083195558f98108cde10b5d6ad0d6865/packages/react-devtools-shared/src/backend/renderer.js#L772
It seems like a WeakSet would be appropriate and would remove the leak. Otherwise we’d need to understand why recordUnmount isn’t called.
CC @bvaughn
Issue Analytics
- State:
- Created 4 years ago
- Reactions:1
- Comments:8
Top Results From Across the Web
Refs and the DOM - React
React will assign the current property with the DOM element when the component mounts, and assign it back to null when it unmounts....
Read more >React - getting a component from a DOM element for debugging
That said, you can at least obtain the React-fiber node for that path, ... However, you can update your initial React.render() call and...
Read more >react-devtools | Yarn - Package Manager
react -devtools. This package can be used to debug non-browser-based React applications (e.g. React Native, mobile browser or embedded webview, Safari).
Read more >MemLab: An open source framework for finding JavaScript ...
Hidden references can cause memory leaks in many unexpected ways. ... or “What is the total retained size of unmounted react components?”.
Read more >A technical breakdown of react-three-fiber - Cody Bennett
At run-time, they are expressed in terms of their target platform. This will be HTML or <foo /> when paired with react-dom and...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Quick update about this issue and PR #17666
The thing that caused the above temporarily “leak” is the alternate pointer- which will be cleared during the next render. That being said, the reason the temporary “leak” retains so much (the whole subtree) is because we weren’t nulling out the
stateNode
field. PR #17666 changes this behavior so that we now will null that field. This should make our memory snapshot comparisons less noisy in the future.In other words, hopefully this will show that DevTools isn’t actually leaking DOM nodes (and Fibers) but if it is at least we should be able to identify them less ambiguously now.
Thanks @bvaughn 👍