Refactorización de CSS en Angular con SMACS y SASS

Contenido del curso

Fundamentos de Arquitectura en CSS

BEM

Atomic Design

OOCSS

SMACSS

ITCSS

TailwindCSS

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:005:10

Refactorización de CSS en Angular con SMACS y SASS

Curso de Arquitecturas CSS

Clase 15 de 19

Clase 15 / 19

Recursos

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.

Fundamentos de Arquitectura en CSS

Arquitectura CSS limpia y escalable

Principios SOLID aplicados a CSS: Guía práctica

BEM

Metodología BEM en CSS explicada

Errores comunes de BEM en HTML

Soluciones a problemas comunes de BEM

Refactorización de Código con Metodología BEM en Proyectos Reales

BEM en el footer de un proyecto Vue

BEM con Styled Components en React

Atomic Design

Atomic Design: átomos a páginas

Atomic Design aplicado en React

Atomic Design en Vue: Organización de Componentes y Carpetas

OOCSS

Principios de OOCSS en CSS

Refactorización de CSS en Angular con OOCSS y SASS

SMACSS

Arquitectura CSS con SMACSS explicada

Refactorización de CSS en Angular con SMACS y SASS

ITCSS

Capas de ITCSS y el triángulo invertido

Limitaciones de ITSSS en Proyectos Pequeños

TailwindCSS

Tailwind CSS com arquitetura CSS profissional

Como escolher entre BEM, ITCSS e CSS frameworks

Refactorización de CSS en Angular con SMACS y SASS

Progreso del curso

Fundamentos de Arquitectura en CSS

BEM

Atomic Design

OOCSS

SMACSS

ITCSS

TailwindCSS

Recursos

Recursos