Aplicar la metodología OOCSS en un proyecto real cambia por completo la forma en que organizamos nuestros estilos. Cuando además combinamos esta técnica con Sass, el resultado es un código más limpio, con menos repetición y mucho más fácil de mantener. A continuación se explica paso a paso cómo se realizó un refactor sobre un componente de tarjeta Pokémon dentro de un proyecto Angular.
¿Cómo está estructurado el proyecto original de Pokémon Team?
El proyecto contiene una carpeta principal llamada components con varios componentes: captura de Pokémon, card de Pokémon, equipo de Pokémon, barra de búsqueda, entre otros [0:08]. La interfaz permite escribir el nombre de un Pokémon en una barra de búsqueda, presionar un botón llamado Search Pokémon, visualizar una tarjeta con la información y agregar ese Pokémon a un equipo.
El componente Pokémon Card es el foco del refactor. Su HTML original incluye:
- Una sección con la clase
pokemon-card como contenedor principal.
- Un
h3 y un img sin clases adicionales.
- Un
ul sin clases, pero cuyos li tienen una clase llamada type que define estilos según el tipo de Pokémon.
¿Qué problema presenta el Sass original?
Al revisar el archivo Sass del componente [1:42], se encuentran múltiples variables y una gran cantidad de clases repetidas. Cada tipo de Pokémon (normal, fuego, agua, etc.) tiene su propia clase con la misma propiedad background-color, pero con un valor distinto. Aunque funciona correctamente, viola el principio DRY (Don't Repeat Yourself) [2:20]: se repite la misma estructura una y otra vez solo para cambiar un color.
¿Cómo se aplica OOCSS junto con Sass para eliminar la repetición?
El refactor se realizó a través de un pull request disponible en los recursos de la clase. Los cambios se concentran en dos archivos: el HTML y el Sass del componente.
¿Qué cambió en el HTML del componente?
La separación fundamental de OOCSS consiste en dividir los estilos en dos categorías: estructura y apariencia [3:08]. En el HTML refactorizado se agregaron clases que reflejan esta separación. A los elementos li se les asignó una clase adicional llamada pokemon-tag junto con la clase del tipo específico. El resultado es un HTML más limpio y mejor estructurado en cuanto a atributos.
¿Cómo se optimizó el Sass con un mapa de colores y un iterador?
En lugar de declarar decenas de variables sueltas, se creó un mapa de Sass llamado $colors [4:00]. Este mapa contiene pares clave-valor donde la clave es el nombre del tipo de Pokémon y el valor es su color correspondiente:
scss
$colors: (
normal: #a8a878,
fire: #f08030,
water: #6890f0,
// ... más tipos
);
Después se utiliza la directiva @each de Sass para iterar sobre ese mapa y generar automáticamente todas las clases [4:15]:
scss
@each $type, $color in $colors {
.#{$type} {
background-color: $color;
}
}
Este iterador reemplaza todas las clases individuales que se repetían en el código original. Con unas pocas líneas se genera el mismo resultado que antes ocupaba decenas de líneas.
¿Cómo quedaron organizados los estilos finales?
Tras el refactor, los estilos quedaron separados en bloques claros [4:48]:
pokemon-card: propiedades de apariencia visual del contenedor.pokemon-card-size: propiedades exclusivas de estructura como ancho, alto y espaciado.pokemon-tag: estilos base para las etiquetas de tipo.pokemon-capture-button: estilos del botón de captura.
Esta organización reduce significativamente las líneas de código y hace que cada clase tenga una responsabilidad clara. La estructura queda desacoplada de la apariencia, lo que facilita reutilizar cualquiera de las dos de forma independiente.
El refactor se aplicó únicamente al componente de la tarjeta. Queda como reto aplicar la misma metodología OOCSS a los demás componentes del proyecto como la barra de búsqueda o el equipo de Pokémon. Si tienes una solución alternativa o un enfoque diferente, compártelo en los comentarios.
