Re: [w3c/webcomponents] How to avoid memory leaks when detecting custom elements? (#674)

> > The problem is that we wouldn't know when a custom element may be defined in the future.
>
> It doesn't matter because if a component is removed and no longer referenced ("destroyed"), then it should be able to destroy the expectation it had for a future element. It doesn't matter if the element is defined in the future or not, just that we clean the memory that was waiting for that future.

What happens when the node is then get inserted back into the document? It is the case that DOM methods such as `appendChild` that [insert](https://dom.spec.whatwg.org/#concept-node-insert) a node momentarily removes the node before inserting it back into the document. This would mean that if you ever move a node from one place to another, it would reject the promise. I don't think that's the behavior you want.

> In this case, if the elements are never defined, then there's something wrong, and I can throw a warning or error after a timeout.

The problem is that you'd never know that. You never when the page had stopped loading more scripts. FWIW, a web page can have a code like `setTimeout(loadCustomElementDefinition(), 1000000 * Math.random())` and just load the custom element definition at an arbitrary time. Worse yet, this could happen in response to network latency, errors, etc...

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/674#issuecomment-335349744