Organizar estilos en un proyecto Angular puede volverse caótico rápidamente si no existe una estructura clara. Aplicar la metodología SMACSS junto con Sass permite separar responsabilidades, reducir archivos dentro de cada componente y mantener un código escalable desde el primer commit.
¿Cómo se estructura un proyecto Angular antes del refactor con SMACSS?
El punto de partida es un proyecto típico de Angular donde cada componente vive dentro de una carpeta Components [0:14]. Dentro se encuentran subcarpetas como Calendar y ReminderCalendar, cada una con sus archivos de HTML y Sass. Los estilos están escritos directamente en el archivo .scss del componente, con valores quemados —colores y tamaños escritos sin variables— lo que dificulta la reutilización y el mantenimiento.
Visualmente el proyecto muestra un calendario sencillo, sin estilos complejos [1:02]. Esa simplicidad es una ventaja a la hora de hacer el refactor, porque permite concentrarse en la organización sin preocuparse por la complejidad visual.
¿Qué cambia al aplicar SMACSS en la arquitectura de estilos?
El refactor consiste en crear una carpeta llamada Styles fuera de los componentes [1:47]. Dentro de ella se generan archivos que corresponden a las categorías de SMACSS: base, layout, module, state y theme, más un archivo de variables. Los archivos Sass de cada componente quedan prácticamente vacíos: solo importan lo que necesitan desde esta estructura centralizada.
¿Qué contiene cada categoría de SMACSS?
- Variables: colores y valores reutilizables que antes estaban escritos directamente en el código [2:10]. Crear este archivo permite llamar cualquier color a nivel global.
- Theme: define estilos de presentación como
title, al que se le asigna un font-weight y un width [2:30].
- State: maneja estados visuales, por ejemplo
is-selected con un color light blue [2:48]. Aunque el archivo sea pequeño, tener los estados separados facilita encontrarlos y modificarlos.
- Module: importa las variables y agrupa clases específicas de componentes como
datepicker, list, reminder y fillreminder [3:05].
- Layout: contiene clases prefijadas con
L- como L-center, L-vertical-center, L-column y L-full-width [3:18]. Este prefijo es una convención propia de SMACSS que indica que la clase controla la disposición general de la página: centrar elementos, definir columnas o establecer anchos completos.
- Base: estilos globales que aplican a elementos HTML sin clase, como
h1 e input [3:45]. Son reglas que afectan a toda la aplicación de forma uniforme.
¿Por qué reducir los estilos dentro de cada componente?
Al mover los estilos a la carpeta Styles, los componentes Calendar y ReminderCalendar conservan únicamente su HTML y un archivo Sass mínimo que importa las categorías necesarias [1:35]. Esto trae beneficios concretos:
- Se elimina la duplicación de valores.
- Cualquier cambio de color o espaciado se hace en un solo lugar.
- La búsqueda de estilos es predecible: si necesitas modificar un estado, vas a
state; si necesitas ajustar la distribución, vas a layout.
¿Qué significa el prefijo L- en SMACSS y cómo se usa en layout?
SMACSS establece que toda clase relacionada con la disposición de página debe llevar el prefijo L- [3:25]. Esto la distingue visualmente de las clases de módulo o de estado. En el proyecto, las clases L-center y L-column controlan cómo se posicionan los elementos a nivel macro, mientras que las clases de módulo como datepicker se encargan de la apariencia interna de cada bloque.
Esta separación es fundamental porque permite que un desarrollador nuevo identifique de inmediato la intención de cada clase solo con leer su nombre.
El pull request de referencia se encuentra en el repositorio bajo la rama curso/arquitectura/CSS/proyecto_7 [0:54]. Si tienes una forma diferente de aplicar SMACSS a este mismo proyecto, comparte tu solución en los comentarios y cuéntanos cómo organizaste las categorías.
