-
Notifications
You must be signed in to change notification settings - Fork 47.9k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Still a "NotFoundError: Failed to execute 'removeChild' on 'Node'" #14740
Comments
Sorry, this is a large blob of code that references your custom components and so it doesn't really tell us much. If you narrow it down to a reproducible case we'd be happy to take a look. Thanks. |
Hey @gaearon sure. I think the relevant part is that this pattern:
generates a
|
Can you try to create a minimal isolated reproducing example? |
This is probably fixed in 16.8.2. If not please file a new issue with a reproducing case. |
I smashed again the error "NotFoundError: Failed to execute 'removeChild' on 'Node'" too.
After reading tons of threads about it I realized it's a pretty common error, however I couldn't figure out how all the provided solutions could apply to my case: I neither do DOM mutations by hand nor swallow exceptions.
I think I can reduce the relevant parts of the code as follows:
SearchDomains.js
DomainItem.js:
I was pretty sure there had to be some messed (async) logic changing the cards under the hood between a render cycle and the next one, so I spent some time trying to debug all the updates, looking for the reason that was driving to an inconsistency in the DOM reconciliation.
Indeed, I figured out the issue was with that ternary operator in the DomainItem's
render
function: dropping temporarily the "else" case, thus, preventing react from removing a content and injecting a different one, switched off the error. Of course this was not an acceptable fix.Then, I realized that everything could be solved by just removing the wrapping
<Fragment>
in the return statement of DomainItem'srender
function. Now everything works fine:Didn't know if this is an intended behaviour so I thought it was worthy to report it.
The text was updated successfully, but these errors were encountered: