Mutation Observer: Auf Änderungen im DOM reagieren

Mutation Observer: Auf Änderungen im DOM reagieren

Entwickler von A/B-Tests und Personalisierungen haben es viel schwerer als ihre Kollegen mit der Macht über das Front- und Backend. Denn sie können das DOM (Document Object Model) nur indirekt beeinflussen und haben immer den Nachteil, die Seite lediglich mit einem einzigen Werkzeug manipulieren zu können – JavaScript.

Das verwenden von JavaScript, um das DOM in der Größenordnung von einem A/B-Test oder einer Personalsierung zu verändern, bringt viele Herausforderungen mit sich. Zwei davon möchte ich vorstellen.

Flickering

Eine der größten Gefahren im A/B-Testing und der Personalisierung ist das Flickering. Das bedeutet, im Worst-Case-Szenario ist die unveränderte Seite einen Augenblick zu sehen, bevor der Test ausgespielt wird. Um Flickering zu vermeiden ist das Timing entscheidend. Es ist zwingend notwendig Elemente aus dem DOM so früh wie möglich mit JavaScript anzusprechen. Das schwierige dabei ist, ist die Punktladung. Denn, greife ich mit JavaScript zu früh auf das DOM zu, bekomme ich einen Fehler weil das Element noch nicht verfügbar war. Bin ich allerdings zu spät, kommt es zum Flicker-Effekt.

Auf dynamisch generierte DOM-Elemente reagieren

Ein weitere Herausforderung, sind dynamische generierte Elemente die in das DOM geladen werden. Element, die also beim initialen Laden der Seite noch nicht verfügbar sind, sondern erst später eingefügt werden. Im optimalen Fall können Events der Seite abgegriffen werden, aber in der Realität stehen einem Entwickler diese Events meist nicht zu Verfügung oder sie sind nicht eindeutig identifizierbar.

DOM Mutation Observer

Eine Lösung für diese Probleme sind DOM Mutation Observer. Mutation Observer reagieren auf jede DOM-Änderung mit Events, die wiederum über ein den Observation-Callback abgegriffen werden können. 

Meine Funktion macht sich diese Eigenschaft der Observer zu Nutze und soll damit das Risiko von Flickering reduzieren und das Problem des Event-Catchings bei dynamisch generierten Elementen lösen.

Die watForElement-Funktion erwartet folgende drei Parameter:

  1. <string> selector – Element auf das gewartet werden soll (CSS Selektor)
  2. <string> target – Der Knotenpunkt der observiert werden soll (z.B. body)
  3. <func> callback – Die Callback-Funktion

Funktionsaufruf:

waitForElement("#element", "body", function() {
   // do something
});

Die Timeout-Funktion simuliert das dynamische nachladen des Elements. In diesem Fall wird der gesamte body observiert, denkbar wäre aber auch ein anderer Knotenpunkt. Nach dem erfolgreichen Einfügen des gesuchten Elements wird über die Callback-Funktion eine Nachricht in der Konsole ausgegeben.

Der Knotenpunkt (target) sollte am besten immer so gewählt werden, dass unnötige Elemente nicht mit observiert werden. Dies könnte sich sonst negativ auf die Performance auswirken – erst recht wenn mehrere Observer zum Einsatz kommen sollen. 

tl;dr

Mutation Observer reagieren auf jede Änderungen des DOMs. Die Events können u.a. dafür verwendet werden, um das Risiko von Flickering bei A/B Tests und Personalisierungen zu minimieren oder um auf dynamisch generierte Elemente zu reagieren.

 Quelle Titelbild: https://pixabay.com/de/code-html-digital-codierung-web-1076533/

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Nächster Beitrag:

Besucher-Herkunft: Was ist der Referrer?

Besucher-Herkunft: Was ist der Referrer?