JavaScript MutationObserver。在观察父元素后观察子元素不会触发任何事件

Question

鉴于此示例代码：

    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
            });
        });
    }

我注意到如果我打电话someMethod(parentElement)然后稍后再打电话someMethod(parentElement.querySelector('someChildElement'))

第一个是唯一触发事件的调用，并且看起来好像第二个调用没有触发任何事件。

不幸的是，因为我最感兴趣的是实际节点被删除时的事件。没有其他的。子节点实际上也不感兴趣，但是选项childList必须data...如此true，所以我猜我是被迫的。

我无法围绕跟踪谁的父级已被跟踪或未被跟踪来组织我的代码，因此我会发现简单地侦听任何特定节点上的删除事件要容易得多，无论它最终以何种方式删除。

考虑到这种困境，我正在考虑MutationObserver在document元素上注册 a ，而是依赖于检测我希望通过自己的事件处理程序观察自己的元素。

但这真的是我最好的选择吗？

性能显然是值得关注的，因为一切都会触发这个文档监听器，但也许只有一个MutationObserver潜在的高效，因为我只会在检测到感兴趣的元素时触发我自己的函数。

然而，它可能需要在removedNodes和addedNodes上进行迭代，因此它对所有事物都有真正的影响，而不仅仅是我观察节点。

这就引出了一个问题，是否已经注册了一个全局突变观察者？

我真的需要自己手动观察文档吗？

如果其他库也开始在主体元素或子元素上观察类似的情况怎么办？

我不会破坏他们的实施吗？（并不是说我只是有依赖性）但这令人担忧这个实现实际上看起来是多么可怕，但考虑到从黎明以来网络上的一切都是多么可怕，这并不奇怪。没有什么是正确实施的。谢谢w3c。

MutationObserver 真的是这样吗？也许有node.addEventListener('someDeleteEvent')我可以听的？

为什么我们被建议远离DOMNodeRemoved类似的活动，但我们真的可以替代吗？特别是因为性能损失似乎是真实的，MutationObserver我想知道为什么到处“聪明人”都建议我们远离DOMNodeRemoved？

他们不一样。无论如何，弃用它们的想法是什么，因为这似乎毫无用处，并且使用起来可能存在问题。

目前，我已经实现了这个全局文档监听器，它允许我仅检测我感兴趣的节点，并在找到时触发我想要的功能。然而，性能可能会受到影响。我不知道。

我正在考虑放弃实施，而是依赖“已弃用”，DOMNodeRemoved除非有人可以提出一些想法。

我的实现只是在文档上注册，然后基本上查看每个元素是否具有自定义事件键，如果有，则触发它。相当有效，但需要类似于以下的迭代：

在整个文档中观察到的每个突变。