2014-06-21 8 views
8

Ich bin vor kurzem auf diese erstaunliche MutationObserver-Funktion gestoßen, die Art von Spuren der Änderungen auf jedem dom-Element zu halten. Ich habe den Code verwendet, der im mozilla developer network angezeigt wurde, kann aber scheinbar nicht laufen lassen. Dies ist der Code, den ich verwenden (link):Wie wird MutationObserver verwendet?

// create an observer instance 
var target = document.querySelector('#something'); 
console.log(target); 
var observer = new WebKitMutationObserver(function(mutations) { 
    mutations.forEach(function(mutation) { 
     console.log("Success"); 
     //$('#log').text('input text changed: "' + target.text() + '"'); 
     //console.log(mutation, mutation.type); 
    });  
}); 
observer.observe(target, { attributes: true, childList: true, characterData: true }); 
//observer.disconnect(); - to stop observing 

// test case 
setInterval(function(){ 
    document.querySelector('#something').innerHTML = Math.random(); 
},1000); 

Der obige Code scheint nicht zu funktionieren. Wenn ich jedoch den gleichen Code mit ein bisschen jQuery modifiziere, scheint alles gut zu funktionieren (Demo here). Gibt es etwas, das mir in der Dokumentation fehlt oder das Beobachtermerkmal falsch interpretiert?

Antwort

8

Sie benötigen subtree: true

http://jsfiddle.net/6Jajs/1/

Der innere Text würde normalerweise ein Kind Text() Element im DOM sein. Ohne den Teilbaum sieht es nur das Element selbst.

Es gibt möglicherweise Verwirrung um "characterData" (https://developer.mozilla.org/en-US/docs/Web/API/CharacterData), aber es scheint, dass das nur für Knoten gilt, die direkt Text enthalten. Das DOM ist so strukturiert, dass die meisten Markup-Elemente einen gemischten Typ enthalten, der optional einen untergeordneten Textknoten enthält (der seinerseits characterData implementieren würde, aber ein Kind des Zielknotens wäre).

+0

Danke für die Klarstellung. Ich sollte mehr recherchieren, bevor ich zu einer Befragung übergehe. :) –

+0

Es ist auch ein Argument, um mit Tools wie jQuery zu bleiben, auch wenn natives JavaScript und die DOM API mächtiger geworden sind. Die zugrundeliegende API soll diese Arten von technischen Details nicht (und IMO sollte nicht) verbergen, so dass eine zusätzliche Ebene der Usability-Abstraktion von Vorteil ist. –