A lo largo de estos primeros artículos hemos logrado desarrollar y poner en práctica la mayoría de conceptos y características que nos brinda Sass de forma básica. Sí aún no has tenido oportunidad de leer los artículos anteriores de nuestra serie, te invito a revisarlos y ponerte al día antes de continuar con la segunda parte.
Ahora me gustaría comenzar a tocar temas un poco más complejos, que te permitan elaborar proyectos de una manera más profesional.
Comencemos: doy por hecho que tienes claro cual es la manera de trabajar de los Mixins y las Funciones. Veamos a continuación, un ejemplo básico de un Mixin:
// map de breakpoints
$breakpoints: (
large: "min-width: 1024px",
medium: "max-width: 1023px",
small: "max-width: 599px"
);
// generar media queries
@mixin respond-to($breakpoint) {
@media (map-get($breakpoints, $breakpoint)) {
@content;
}
}
// cómo usarlo:
body {
@include respond-to(large) {
background-color: red;
};
}
Básicamente, tenemos lo siguiente:
- Variable de tipo map en la que guardamos los valores que utilizaremos en nuestro Mixin.
- Creamos el Mixin y definimos un argumento requerido ($breakpoint). Luego, usamos la función map-get para intentar devolver un valor asociado al argumento ($breakpoint) en la variable de tipo map explicada en el punto 1.
- Por último, usamos el Mixin. Por el momento para dejar el ejemplo sencillo, le pedimos a Sass que el body tenga de fondo un color rojo cuando el ancho de la pantalla de nuestro navegador sea cómo mínimo de 1024px.
Por ahora todo funcionará, si procesamos el código a CSS tendremos la siguiente impresión:
@media (min-width: 1024px) {
body {
background-color: red;
}
}
Problema:
Aparentemente, el funcionamiento es exitoso, nos permite trabajar con media queries de una manera bastante cómoda.
Vamos a recapitular un poco, el argumento que pasamos al Mixin debe ser, obligatoriamente, una llave asociada a un valor que se encuentre en la variable $breakpoints. Si no cumplimos esta premisa, la función map-get no encontrará lo que busca e imprimirá null, produciendo un error a la hora de procesar de Sass a CSS.
Vamos a reproducir el error cambiando un poco la llamada al Mixin:
// la llave "foo" no existe dentro de la variable $breakpoint.
// Llaves disponibles: large, medium, small.
body {
@include respond-to(foo) {
background-color: red;
};
}
En nuestra terminal, podemos apreciar que la ejecución de Sass nos alerta de que algo anda mal:
error main.scss (Line 13: Invalid CSS after "(": expected expression (e.g. 1px, bold), was ")")
Nada claro, ¿cierto? Sería mucho mejor si pudiéramos, de alguna manera, cambiar el mensaje por algo más explícito que nos ayude a detectar el error más fácilmente ¿están de acuerdo? Manos a la obra.
Solución:
Sass nos provee de dos directivas muy útiles: @error y @warn. Es justo lo que necesitamos para personalizar los mensajes de alerta y error.
La diferencia entre ambas es muy simple: @error corta en seco y no permite continuar hasta tanto el error no se haya corregido. En cambio, la directiva @warn es más flexible, simplemente imprimirá en nuestra consola un mensaje de advertencia; cuidado, todo va bien pero debes estar alerta, cualquier paso en falso puede producir un error fatal.
Para terminar de mejorar nuestro Mixin, vamos a utilizar la directiva @error para mostrar el mensaje y una función para manipular maps que viene integrada con Sass, se llama map-has-key.
La función map-has-key comprueba si una variable de tipo map tiene un valor asociado a la llave, devolverá verdadero (true) o falso (false) y recibe únicamente dos argumentos: $map, $key.
- $map variable de tipo map que deseamos manipular.
- $key la llave a comprobar si se encuentre o no dentro del $map.
Aclarado todo lo que utilizaremos, sigamos:
@mixin respond-to($breakpoint) {
// comprobamos si el argumento ($breakpoint) no se encuentra en la variable de tipo map.
@if not map-has-key($breakpoints, $breakpoint) {
// sí la comprobación es verdadera
// le decimos a Sass que imprima el siguiente error.
@error "La llave #{$breakpoint}, no se encuentra entre las disponibles.";
}
@media (map-get($breakpoints, $breakpoint)) {
@content;
}
}
Pasamos de:
error main.scss (Line 13: Invalid CSS after "(": expected expression (e.g. 1px, bold), was ")")
A un bonito mensaje, que nos ayudará a detectar y depurar más rápidamente el error:
La llave #{$breakpoint} no se encuentra entre las disponibles.
Pueden revisar y jugar un rato con un ejemplo un poco más completo que realicé en mi Codepen con motivo de este artículo.
Conclusión:
Sass es un pre-procesador muy poderoso, brinda muchas características que nos ayudarán en nuestro día a día. Mensajes que alerten con claridad sobre los errores, reducirán drásticamente el tiempo que pasamos detectando, depurando y podremos emplearlo en otras tareas. Al final del día seremos más felices, se los aseguro.
Para finalizar, comentarles que estoy retomando la serie y de ahora en adelante los nuevos artículos se publicarán cada 2 semanas. Espero los disfruten.
Regístrate hoy en Styde y obtén acceso a todo nuestro contenido.
Lección anterior Aprende Sass: Tipo de Dato Maps y Funciones Lección siguiente Aprende a crear un Grid System con Sass