← Tutti gli articoli

API e helper

Scrivere regole JS che sopravvivono ai cambiamenti del DOM

15 maggio 2026 · di JustZix Team

Hai scritto una regola, ha funzionato una settimana, oggi si è fermata. La pagina non si è rotta — ha solo rinominato una classe da .btn-primary a .Button_primary_x7f3. Ecco come scrivere regole che sopravvivono a cambiamenti del genere.

Perché le regole si rompono

Una regola si aggrappa al DOM di una pagina che non controlli. Ogni restyling, ogni build con un nuovo hash di classe, ogni test A/B può spostare il terreno sotto i tuoi piedi. Non puoi eliminarlo — puoi limitarlo.

Regola 1 — punta a ciò che è stabile

Selettori dal più al meno duraturo:

• Il meglio: attributi semantici — [aria-label], [role], [name], [type], [data-testid]. Cambiano raramente, perché portano significato.
• Buono: tag e la loro struttura — nav a, main > article.
• Rischioso: classi leggibili da un umano — .sidebar, .cookie-banner.
• Il peggio: classi con hash — .css-1a2b3c, .jsx-987. Generate al build, cambiate a ogni deploy.

Regola 2 — punta col testo quando le classi falliscono

Il testo visibile all'utente cambia meno spesso delle classi CSS. Invece di catturare un pulsante per classe, trovalo per contenuto:

const btn = [...document.querySelectorAll('button')]
  .find(b => /salva|invia|save|submit/i.test(b.textContent || ''));

Regola 3 — controlla sempre che l'elemento esista

Una regola che presume che un elemento ci sia esploderà il giorno in cui manca — e spesso ucciderà il resto del proprio codice. Scrivi in modo difensivo:

const el = document.querySelector('.target');
if (el) {
  // lavoro qui
}

L'operatore ?. lo fa in modo conciso: document.querySelector('.target')?.remove() non fa nulla quando l'elemento è assente — invece di lanciare un errore.

Regola 4 — lascia che la regola gridi quando si perde

Il guasto peggiore è uno silenzioso — la regola non funziona e non sai perché. Aggiungi un segnale:

const el = document.querySelector('.target');
if (!el) JUSTZIX.warn('Regola X: .target non trovato — pagina cambiata?');

Una voce nell'Output Console ti dice subito che è ora di correggere il selettore — invece di indovinare.

Vedi anche

• MutationObserver nelle regole — resistenza ai cambiamenti nel tempo
• Output Console come logger — dove atterrano i segnali delle regole
• Pattern di URL — la resistenza comincia dalla corrispondenza

Installa JustZix — e scrivi regole che non si rompono al prossimo deploy della pagina.