React v16: Error during mount causes instance to never be removed from mountedInstances
See original GitHub issueI’m guessing componentWillUnmount
isn’t called. Would a fix be to listen to componentDidCatch
, splice the array as in componentWillUnmount
and then rethrow the error?
Issue Analytics
- State:
- Created 6 years ago
- Reactions:1
- Comments:33 (5 by maintainers)
Top Results From Across the Web
Error Boundaries - React
Error boundaries are React components that catch JavaScript errors anywhere in their child component tree, log those errors, and display a fallback UI...
Read more >The Guide to Learning React Hooks (Examples & Tutorials)
Includes tutorials and code examples on using hooks for state and effects, ... Only call Hooks from React functional components; Never call a...
Read more >ReactDOM.render is no longer supported in React 18 - Stack ...
In your file index.js, change to: import React from "react"; import ReactDOM from "react-dom/client"; import "./index.css"; import App from ...
Read more >React Lifecycle - W3Schools
Mounting means putting elements into the DOM. React has four built-in methods that gets called, in this order, when mounting a component: constructor() ......
Read more >8 common React error messages and how to address them
React Hooks must be called in the exact same order in every component render; React Hook has a missing dependency: 'XXX'. Either include...
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 FreeTop 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
Top GitHub Comments
Side effects are only safe in the commit phase (after render).
I think maybe the right fix is for every component in their commit-phase hooks to find the root component (through context) and cause it to call
setState
on itself (maybe passing depth as an argument).Components themselves just return
this.props.children
from render so that should always be memoized andsetState
on the root shouldn’t cause a deep re-render. Since we’re already inside the lifecycle, it should get batched and be processed after all suchsetState
s. Resulting in a single “flush” after all inner components have updated their props.Finally, the root component flushes changes in its own
componentDidUpdate
hook.