JS-Regeln schreiben, die DOM-Änderungen überstehen
Du hast eine Regel geschrieben, sie funktionierte eine Woche, heute hat sie aufgehört. Die Seite ist nicht kaputtgegangen — sie hat nur eine Klasse von .btn-primary in .Button_primary_x7f3 umbenannt. So schreibst du Regeln, die solche Änderungen überleben.
Warum Regeln kaputtgehen
Eine Regel klammert sich an das DOM einer Seite, die du nicht kontrollierst. Jedes Redesign, jeder Build mit neuem Klassen-Hash, jeder A/B-Test kann dir den Boden unter den Füßen wegziehen. Das kannst du nicht beseitigen — du kannst es begrenzen.
Regel 1 — ziele auf das Stabile
Selektoren von am haltbarsten bis am wenigsten:
- Am besten: semantische Attribute —
[aria-label],[role],[name],[type],[data-testid]. Sie ändern sich selten, weil sie Bedeutung tragen. - Gut: Tags und ihre Struktur —
nav a,main > article. - Riskant: menschenlesbare Klassen —
.sidebar,.cookie-banner. - Am schlechtesten: gehashte Klassen —
.css-1a2b3c,.jsx-987. Beim Build generiert, bei jedem Deploy geändert.
Regel 2 — ziele über Text, wenn Klassen versagen
Für den Nutzer sichtbarer Text ändert sich seltener als CSS-Klassen. Statt einen Button über die Klasse zu fangen, finde ihn über den Inhalt:
const btn = [...document.querySelectorAll('button')]
.find(b => /speichern|senden|save|submit/i.test(b.textContent || ''));Regel 3 — prüfe immer, ob das Element existiert
Eine Regel, die annimmt, dass ein Element da ist, fliegt an dem Tag auseinander, an dem es fehlt — und tötet oft den Rest ihres eigenen Codes. Schreibe defensiv:
const el = document.querySelector('.target');
if (el) {
// Arbeit hier
}Der ?.-Operator macht es knapp: document.querySelector('.target')?.remove() tut nichts, wenn das Element fehlt — statt zu werfen.
Regel 4 — lass die Regel schreien, wenn sie sich verirrt
Die schlimmste Störung ist eine stille — die Regel funktioniert nicht und du weißt nicht warum. Füge ein Signal hinzu:
const el = document.querySelector('.target');
if (!el) JUSTZIX.warn('Regel X: .target nicht gefunden — Seite geändert?');Ein Eintrag in der Output Console sagt dir sofort, dass es Zeit ist, den Selektor zu reparieren — statt zu raten.
Siehe auch
- MutationObserver in Regeln — Widerstandsfähigkeit gegen Änderungen über die Zeit
- Output Console als Logger — wo Regelsignale landen
- URL-Muster — Widerstandsfähigkeit beginnt mit der Übereinstimmung
Installiere JustZix — und schreibe Regeln, die beim nächsten Seiten-Deploy nicht kaputtgehen.
Bewerte diesen Beitrag
Noch keine Bewertungen — sei der Erste.