Refactorización de CSS en Angular con OOCSS y SASS

Aplicar la metodología OOCSS en un proyecto Angular con Sass te permite separar estructura de apariencia, eliminar clases repetidas y aprovechar iteradores de Sass para escribir menos código. Esta guía es para desarrolladores frontend que ya trabajan con componentes y quieren un CSS más limpio y mantenible.

¿Qué proyecto vamos a refactorizar con OOCSS?

Partimos de un proyecto Angular tipo Pokédex que dejó un estudiante. La interfaz tiene una barra de búsqueda donde escribes el nombre de un Pokémon, presionas el botón Search Pokémon, aparece una tarjeta con su información y luego puedes añadirlo a un equipo.

Dentro del repositorio existe una carpeta principal llamada components con varios elementos: capture Pokémon, Pokémon card, Pokémon team y search bar, entre otros. El refactor lo enfocamos en el componente Pokémon Card, aunque la misma lógica aplica al resto.

¿Cómo está estructurado el componente Pokémon Card antes del refactor?

El HTML original tiene un section con la clase Pokémon Card, un H3, una imagen sin clase, un UL sin clase y varios LI con una clase type. Esa clase type cambia los estilos según el tipo de Pokémon.

En el archivo Sass encontramos variables, los estilos del contenedor Pokémon Card, los del botón Capture Pokémon Button y varias media queries. El detalle curioso: existían múltiples clases distintas, una por cada tipo de Pokémon, repitiendo la misma propiedad background-color con valores diferentes.

¿Qué problema resuelve OOCSS aquí? Evita repetir la misma propiedad CSS en clases distintas que solo cambian el valor. Separa estructura y apariencia para reutilizar estilos entre componentes.

¿Cómo separar estructura y apariencia en el HTML?

La primera regla de OOCSS es dividir lo estructural de lo presentacional. En el pull request del refactor abrimos el archivo HTML y vemos el cambio: el section ahora combina clases que describen forma y otras que describen apariencia.

En los LI agregamos una clase adicional llamada Pokémon tag junto a la clase del tipo. Así, Pokémon tag define la estructura del elemento (forma, espaciado, tipografía) y la clase del tipo solo se encarga del color.

El resultado: un HTML más limpio, con atributos mejor organizados y clases que comunican intención.

¿Cómo reducir clases repetidas con un iterador en Sass?

Aquí entra la magia de Sass. En lugar de declarar una clase por cada tipo de Pokémon repitiendo background-color, creamos una variable tipo mapa llamada colors que contiene pares clave-valor: el nombre del tipo (normal, fire, etc.) y su color correspondiente.

Después usamos un iterador de Sass que recorre ese mapa y genera, en una sola estructura, todas las clases necesarias asignando el background-color adecuado a cada tipo. Una herramienta del propio Sass nos ahorra decenas de líneas.

¿Qué es un iterador en Sass? Es una directiva como @each que recorre los elementos de un mapa o lista y genera reglas CSS dinámicamente, evitando escribir clases repetitivas a mano.

¿Cómo queda el Sass refactorizado?

El archivo final organiza los estilos en bloques claros:

• Pokémon Card: contiene las propiedades visuales del contenedor.
• Pokémon Card Size: agrupa lo estructural relacionado con tamaño.
• Pokémon Tag: define la apariencia base de cada etiqueta de tipo.
• Pokémon Capture Button: estilos del botón de captura.

Con esta separación cumples el principio don't repeat yourself, reduces líneas de código y dejas un Sass mucho más legible para quien continúe el proyecto.

¿Por qué importa este refactor en proyectos reales?

Cuando un componente crece, repetir propiedades CSS en clases distintas se vuelve insostenible. Aplicar OOCSS junto con las capacidades de Sass te da tres ventajas concretas:

1. Menos código duplicado y archivos más cortos.
2. Clases reutilizables entre componentes parecidos.
3. Mantenimiento más rápido cuando cambian colores, tamaños o tipografías.

Y aquí viene lo interesante: este patrón no es exclusivo del Pokémon Card. Los mismos principios funcionan en search bar, Pokémon team y capture Pokémon.

¿Ya intentaste refactorizar otro componente del proyecto con OOCSS? Crea tu propio pull request, prueba una solución distinta para la tarjeta y cuéntanos en los comentarios cómo te fue. Si tienes una variante del refactor usando esta metodología, compártela también.