← Wszystkie wpisy

API i helpers

Reguły JS odporne na zmiany w DOM strony

Napisałeś regułę, działała tydzień, dziś przestała. Strona się nie zepsuła — po prostu zmieniła klasę z .btn-primary na .Button_primary_x7f3. Oto jak pisać reguły, które przeżyją takie zmiany.

Dlaczego reguły się psują

Reguła trzyma się DOM-u strony, której nie kontrolujesz. Każdy redesign, każdy build z nowym hashem klasy, każdy test A/B może przesunąć grunt pod nogami. Nie da się tego wyeliminować — da się ograniczyć.

Zasada 1 — celuj w to, co stabilne

Selektory od najbardziej do najmniej trwałego:

Zasada 2 — celuj tekstem, gdy klasy zawodzą

Tekst widoczny dla użytkownika zmienia się rzadziej niż klasy CSS. Zamiast łapać przycisk po klasie, znajdź go po treści:

const btn = [...document.querySelectorAll('button')]
  .find(b => /zapisz|wyślij/i.test(b.textContent || ''));

Zasada 3 — zawsze sprawdzaj, czy element istnieje

Reguła, która zakłada, że element jest, wywali się w dniu, gdy go zabraknie — i często ubije resztę swojego kodu. Pisz obronnie:

const el = document.querySelector('.target');
if (el) {
  // praca tutaj
}

Operator ?. robi to zwięźle: document.querySelector('.target')?.remove() nic nie zrobi, gdy elementu nie ma — zamiast rzucić błędem.

Zasada 4 — niech reguła krzyczy, gdy się zgubi

Najgorsza awaria to cicha awaria — reguła nie działa, a Ty nie wiesz dlaczego. Dołóż sygnał:

const el = document.querySelector('.target');
if (!el) JUSTZIX.warn('Reguła X: nie znalazłem .target — strona zmieniona?');

Wpis w Output Console od razu mówi, że czas poprawić selektor — zamiast zgadywać.

Zobacz też

Zainstaluj JustZix — i pisz reguły, które nie psują się przy następnym deployu strony.

Oceń ten wpis

Brak ocen — oceń jako pierwszy.

Wypróbuj samodzielnie

Zainstaluj JustZix i wklej dowolny snippet z tego artykułu. Dwie minuty od zera do działającej reguły na wszystkich Twoich urządzeniach.

Pobierz JustZix

Funkcje · Jak to działa · Przykłady · Zastosowania