html - JavaScript MutationObserver. Observing a child element after observing a parent element triggers no events

Question

Given this sample code:

    function someMethod(elements) {
        
        var observer = new MutationObserver(function(events) {
            
            SomeLib.each(events, function(event, k, i) {
                if ( event.removedNodes ) {
                    SomeLib.each(event.removedNodes, function(removedElement, k, i) {
                        console.log(222, removedElement)                       
                    });
                }
            });
        });
        
        SomeLib.each(elements, function(element, k, i) {
            console.log(111, element)
            
            observer.observe(element, {
                childList    : true,
                subtree      : false
            });
        });
    }

I've noticed that if I call someMethod(parentElement) and then call it again later someMethod(parentElement.querySelector('someChildElement'))

The first one is the only one that triggers events and appears as if the second call does not trigger any events.

This is unfortunate as I am mostly interested in an event when the actual node is removed. Nothing else. Child nodes are really not of interest either, but childList or data... option has to be true so I am forced to I guess.

I can not organize my code around keeping track of who's a parent is already tracked or not, and therefore I would have found it much easier to simply listen to remove events on any particular node, whatever way it is eventually deleted.

Considering this dilemma, I am considering registering a MutationObserver on the document element and instead rely on detecting the element I wish to observe myself through my own event handler.

But is this really my best option?

Performance is obviously of concern since everything will fire this document listener, but perhaps just having one MutationObserver potentially efficient since I will only be triggering my own function when I detect the element of interest.

It requires iteration however, on removedNodes and addedNodes potentially, so it has a real effect on everything rather than just me observing the node.

This begs the question, is there not already a global mutation observer already registered?

Do I really have to manually observe the document myself?

What if other libraries also start to observe things similarly either on body or child elements?

Won't I destroy their implementation? (Not that I have just dependency) but this is worrying how horrible this implementation really seems to be, but not surprising considering how everything has been horrible with the web since the dawn of day. Nothing is ever correctly implemented. Thank you w3c.

Is MutationObserver really the way here? Perhaps there are node.addEventListener('someDeleteEvent') I can listen to instead?

Why are we being recommended away from DOMNodeRemoved like events, but can we really do the replacement? Especially since performance penalty seems real using MutationObserver I wonder why everywhere "smart people" are recommending us away from DOMNodeRemoved?

They are not the same. What is the idea of deprecating those anyway since this seems kind useless and potentially problematic to use.

For now, I have already implemented this global document listener that allows me to detect nodes I am interested in only, and fire the functions I desire when found. However, performance might be hit. I am not sure.

I am considering scrapping the implementation and instead rely on "deprecated" DOMNodeRemoved regardless unless someone can chip in with some thoughts.

My implementation simply registered on document and then basically looks at each element if they have the custom event key on them, and fire it if they do. Quite effecient but requires iteration similar to:

On each mutation observed across entire document.

Answer 1

Waitting for answers