undom

I'm trying to spy on in a test - I have a node being modified like this: To my surprise, it was counting way too many calls to . It turns out, several of these methods are being called internally, for brevity. The real DOM does not call it's own public methods, afaik? If it needs to remove children for other reasons than calls to , it does not internally call the method, it just removed them. How would you feel about moving the internally reused methods to private methods?

I tried using this for a unit-test, and ran into some issues with e.g. , which in regular DOM is a NodeList and not just an , which is missing, for example, the , and iterator methods. I can foresee issues as well with e.g. being a plain created by filtering - whereas, in regular DOM, mutating the of the parent that generated the collection, would cause the iterator to reflect those changes. Maybe this is "by design", favoring simplicity over correctness? If so, that isn't clear from the "Project Goals" stated in the README right now - it doesn't seem to imply that this deviates from DOM in terms of more than features. Lacking features is a matter of scope - but incompatibilities probably ought to be designated in the documentation?

Would be cool to have "undom" published on deno.land (https://deno.land/x/undom) so it's easier to import in Deno. Setup guide