Dandole vuelta a la cascada usando Custom Properties
Tags: css, web, webdev, frontend
Published: 2024-03-12 08:41:45

Hace unos días tuve un problema con CSS (en realidad eso es todos los días), desarrollando unas features me di cuenta de algo realmente feo que estaba pasando.

## El problema

**¡¡¡Mis estilos estaban siendo sobre-escritos!!!**. Esto es un problema común cuando no se tiene una metodología o un estándar para hacer CSS. Estos problemas son normalmente por no tener en cuenta como la ubicación del CSS, la cascada y la especifidad afectan a tus elementos.

En mi caso la raíz de todo fue la cascada y no la especificidad ni el [origen](https://developer.mozilla.org/es/docs/Learn/CSS/Building_blocks/Cascade_and_inheritance#el_efecto_de_la_ubicaci%C3%B3n_del_css). La cascada decide que estilo se aplica y cual no, cuando estos tiene la misma prioridad.

## El origen del problema

En orden de prioridades esta:
* Importancia (!important)
* La especificidad
* Orden

El orden es el último de los factores a tomarse en cuenta. En un proyecto de desarrollo es común que los estilos se repitan porque hay elementos muy similares, con el enfoque de componentes esto se mitiga pero aun pasa.

La recomendación es usar CSS modules para evitar conflictos en elementos similares (al menos en nombres), usar alguna metodología para el naming de clases (como [BEM](https://getbem.com/)) y metodlogía una de estructura ([OOCSS](https://github.com/stubbornella/oocss/wiki)). Nota: no necesariamente deben usar 2 a la vez, BEM es mas simple en cuestion de que organizamos por componentes, pero eventualmente llegamos a la conclusión de que debemos separar la estructura (layout, paddings, margins, características no visuales) de una capa de presentación (colores, bordes, elementos visuales).

## Y el problema?

Bueno básicamente pese a tener todo eso, por alguna razón el framework que usabamos inyectaba los estilos en un orden extraño. Todas eran hojas de estilo externas, todos los estilos tenían la misma especificidad pero el orden de como se agregaban al bundle era diferente (no sabemos porque solo lo sabemos).

Imagina el siguiente ejemplo. Tengo un botón y este usa una variante que se llama Button--super que solo uso en un lugar por ende no hace sentido hacerla reusable (este mindset no siempre es válido).

Esa clase solo afecta el borde del botón, las otras clases no pueden eliminarse porque agregan estilos necesarios y de hacerlo tendría que duplicar código ademas de que no se agregarían updates a mi Button Super Saiyajin. Bueno sigamos con el código.

```html
<button class="Button Button--default">My Button</button>
<button class="Button Button--default Button--super">My Super Button</button>
```

Y el CSS es el siguiente

```css
/* En tu componente */
.Button--super {
  border-color: yellow;
}

/* En el componente base */
.Button {
  padding: 0.5rem;
}

.Button--default {
  background: transparent;
  font-weight: bold;
  border-color: black;
}
```

![Botones a nivel UI iguales](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/vthnot2dy49m48bw1jdx.png)

Ahora considera que sea un componente crítico, puedes modificarlo pero en algunos casos puede haber snapshots que usen ese componente, alterarías el orden natural de las cosas tronando los tests y causando una marea de mensajes de slack justo a tu hora de la salida.

Bueno, tan simple como agregar un !important y ya, bueno eso sería algo simple resolveríamos el problema. Ahora imagina que en algun punto vas a definir otros N botones que cambien alguna de esas propiedades definidas en estilos que se estan sobreescribiendo por el orden en que se estan inyectando (no es sobreingeniería, eso va a pasar).

No puedes remover esos estilos y redefinir el componente claramente no es una opción por su uso, entonces ¿que haces? ¿llorar? (hice eso un rato)

## Solución al problema

Bueno, ninguna solución esta libre de inconvenientes:
- Important, important everywhere: No
- Incrementar la especificidad: complicado si usas css modules
- Incrementar especificidad agregando data attributes: Me gusta pero cambiaría la estructura y no quiero eso
- Custom properties y usando los valores por default como fallback: me quedo con esta

![Shut up and take my money](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/50of8h6bz8lp15wgzd4z.png)

¿Porque me gusta? Porque no cambio la estructura del componente, si uso un design system me es mucho más fácil definir el cambio de propiedades por temas en lugar usar un selector y puedo definir propiedades que se propagan mediante la cascada.

> Es mucho más fácil cometer un error sobreescribiendo un estilo que una custom property.

![No tengo pruebas pero tampoco dudas](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/nkeap5qgyrs289gkvsba.png)


No se si sea cierto, lo acabo de inventar XD, pero normalmente las custom properties de una aplicación se definen en el :root de una aplicación y este selector tiene una especificidad menor a la de una clase por ende podemos sobreescribirla usando clases especificas para nuestro componente. 

Ojo, tampoco son infalibles, puedes cometer los mismos errores. Para evitar minimizarlos debes definir ciertas reglas.

1. Definir un prefijo para evitar conflictos en nombre de variables. Es caso de componentes core no hay tanto problema. En mi caso será `button-`.

2. Tu componente core, en este caso el Botón solo usará fallbacks para definir el valor de su estilo, inclusive sus variantes y debe depender del valor de una custom property. Ejemplo:

```css
.Button--default {
  background: transparent;
  font-weight: bold;
  border-color: var(--button-border-color, black);
}
```

Si esa propiedad no esta definida en ese nodo ya sea que este definida mediante una clase o por herencia.

Al final puedes tener algo así y aunque la cascada quiere pasarte una mala jugada pues estás preparado.

```
.Button--super {
  --button-border-color: yellow;
}

.Button {
  padding: 0.5rem;
}

.Button--default {
  background: transparent;
  font-weight: bold;
  border-color: var(--button-border-color, black);
}
```

![Super botón con borde amarillo y boton con bordes negros, problema solucionado](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/rvsf5ja68hk72qekqwtc.png)

No resolverá todos los problemas, pero te ayuda a pensar que partes de tu componente a nivel de estilos podrías exponer en una interfaz con la intención de que estuviera abierta a extensiones pero cerrado a modificaciones (SOLID eres tu? XD). 

Una desventaja es que hay que recordar nombres de variables y puede ser una carga cognitiva pero nada es gratis en esta vida.

Si quieres ver este pequeño ejemplo funcionando te dejo el [codepen](https://codepen.io/dezkareid/pen/QWPEwXe).

BTW voy a estar publicando como usar [@layer](https://developer.mozilla.org/en-US/docs/Web/CSS/@layer) también evitar que tus estilos sean sobre escritos, en un futuro no muy lejano