← Todos los artículos

API y helpers

Escribir reglas JS que sobreviven a los cambios del DOM

15 mayo 2026 · por JustZix Team

Has escrito una regla, funcionó una semana, hoy se ha detenido. La página no se ha roto — solo ha renombrado una clase de .btn-primary a .Button_primary_x7f3. Aquí está cómo escribir reglas que sobreviven a cambios así.

Por qué se rompen las reglas

Una regla se aferra al DOM de una página que no controlas. Cada restyling, cada build con un nuevo hash de clase, cada test A/B puede mover el terreno bajo tus pies. No puedes eliminarlo — puedes limitarlo.

Regla 1 — apunta a lo que es estable

Selectores del más al menos duradero:

• Lo mejor: atributos semánticos — [aria-label], [role], [name], [type], [data-testid]. Cambian rara vez, porque llevan significado.
• Bueno: tags y su estructura — nav a, main > article.
• Arriesgado: clases legibles por un humano — .sidebar, .cookie-banner.
• Lo peor: clases con hash — .css-1a2b3c, .jsx-987. Generadas en el build, cambiadas en cada deploy.

Regla 2 — apunta con el texto cuando las clases fallan

El texto visible para el usuario cambia menos a menudo que las clases CSS. En lugar de capturar un botón por clase, encuéntralo por contenido:

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

Regla 3 — comprueba siempre que el elemento exista

Una regla que presume que un elemento está ahí explotará el día en que falte — y a menudo matará el resto de su propio código. Escribe de forma defensiva:

const el = document.querySelector('.target');
if (el) {
  // trabajo aquí
}

El operador ?. lo hace de forma concisa: document.querySelector('.target')?.remove() no hace nada cuando el elemento está ausente — en lugar de lanzar un error.

Regla 4 — deja que la regla grite cuando se pierde

El fallo peor es uno silencioso — la regla no funciona y no sabes por qué. Añade una señal:

const el = document.querySelector('.target');
if (!el) JUSTZIX.warn('Regla X: .target no encontrado — ¿página cambiada?');

Una entrada en la Output Console te dice enseguida que es hora de corregir el selector — en lugar de adivinar.

Mira también

• MutationObserver en las reglas — resistencia a los cambios en el tiempo
• Output Console como logger — dónde aterrizan las señales de las reglas
• Patrones de URL — la resistencia empieza por la coincidencia

Instala JustZix — y escribe reglas que no se rompen en el próximo deploy de la página.