WebReflection / uhtml

A micro HTML/SVG render

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Failed to execute 'removeChild' on 'Node': The node to be removed is not a child of this node.

ivantacca opened this issue · comments

Hello, we are experiencing this issue on our web app:
sometimes, when we have state changes and update() is fired, the entire app stop working and the console shows this error:

Failed to execute 'removeChild' on 'Node': The node to be removed is not a child of this node.

We are trying to find a workaround for this problem and we will send a PR once solved

uhtml owns its nodes, if there is any code that change nodes, replace nodes, without passing through uhtml render, it will break.

the issue is not in this library, it's likely in third party code you are running over nodes handled by this library.

I have seen this issue when "debouncing" my updates using requestAnimationFrame. Calling the updates synchronously seems to cure the issue.

Andrea, could you give us an idea of what kinds of changes are safe? I've been assuming that adjusting attributes not specified via uthml should be safe. For example, I need to adjust the size of a div when an image is resized. I'm using resizeObserver to adjust the left, top, width, height of the div. I'd guess that is safe.Is it?

All changes are safe, as long as these don't interfere with the dynamic parts handled by the library.

If you declare children in a part of the node content, you can't remove or add one or any children in that part of the node.

If you declare attributes state, you better re-render with a new state instead of changing that manually.

In few words uhtml owns the content it renders, and renders are extremely fast and cheap. Changing anything manually is likely already a micro optimization that won't bring any concrete benefit but, potentially, cause more issues than it solves.

Inner renders are also a good way to isolate updates around a single component, uce does that well, as example.

P.S. that being said, the next major release of uhtml will drop support for IE/legacy Edge down its whole stack, hence it will use element.remove() instead of parentNode.removeChild(element) ... that will mess up if a node has been manually moved somewhere else (it'll be removed) but at least it will stop throwing errors.

... now that I've written that, I am also not sure anymore I should do it, as that will be a silent error instead of a well known reason for having an error in the wild ... i.e. obtrusive third party code that does stuff it shouldn't do.

Thanks! This is such a great tool and I'm pleased that my mental model is gradually conforming to reality.

I'll take my next question over to the discussions page.

no much time these days and not convinced I want to fix this as it's a 3rd party issue, not a uhtml one. Closing for now.