Sass Best Practices Consejos y herramientas para desarrolladores

Al igual que jQuery revolucionó vainilla JavaScript, Sass ha revolucionado el CSS de vainilla.. La mayoría de los desarrolladores que aprenden Sass están de acuerdo en que nunca querrían volver. Muchos también están de acuerdo en que el mayor problema con los nuevos desarrolladores es el camino Ellos usan Sass, no Sass mismo..

He rastreado la web y compilado este artículo de Mejores prácticas para escribir código Sass expandible y reutilizable.. Las sugerencias provienen de mis propias opiniones y de sitios web de confianza como las Directrices Sass.

Ciertamente no necesita implementar todas estas características en su flujo de trabajo. Pero vale la pena al menos entretener estas ideas y contemplar los beneficios potenciales.

Organización de archivos

El mejor lugar para comenzar con el desarrollo de Sass es la organización de archivos. Si ya está en el código modular, debe comprender el valor de las importaciones y los parciales (más sobre esto más adelante).

Pero por ahora solo eche un vistazo a este ejemplo de estructura de archivos de DoCSSa. He recreado esta estructura de archivos que puedes ver a continuación:

Esta es solo una sugerencia y es una de las muchas maneras en que podría organizar sus archivos. Puedes encontrar otros métodos que usan diferentes estructuras de carpetas como “globales” para todo el sitio SCSS y “páginas” para SCSS de página específica.

Veamos este estilo de organización sugerido para examinar el propósito de cada carpeta:

• / globals - contiene archivos Sass que se aplican en todo el sitio como tipografía, colores y cuadrículas
• / componentes - contiene archivos Sass con estilos de componentes como botones, tablas o campos de entrada
• / secciones - contiene archivos Sass dedicados a páginas o áreas específicas en una página (podría funcionar mejor combinada en la carpeta / components /)
• / utiles - contiene utilidades de terceros como Normalize que se pueden actualizar dinámicamente con herramientas como Bower.
• main.scss - el archivo Sass primario en la carpeta raíz que importa todos los demás.

Este es solo un punto de partida básico y hay mucho espacio para expandir con sus propias ideas..

Pero no importa cómo elija organizar su SCSS, es crucial que tener alguna organización con un archivo (o carpeta) separado para bibliotecas como Normalizar que deben actualizarse, más componentes en parciales de Sass para su proyecto.

Los parciales de Sass son vitales para las mejores prácticas modernas. Estos son altamente recomendados por el equipo de diseño de Zurb y por muchos otros desarrolladores profesionales de frontend..

Aquí hay una cita del sitio web de Sass que explica los parciales:

“Puede crear archivos Sass parciales que contienen pequeños fragmentos de CSS que puede incluir en otros archivos Sass. Esta es una gran manera de Modular tu CSS y ayudar a mantener las cosas más fáciles de mantener. Un parcial es simplemente un archivo Sass nombrado con un guión bajo. Usted podría llamarlo algo como _partial.scss. El subrayado le permite a Sass saber que el archivo es solo un archivo parcial y que no debe generarse en un archivo CSS. Los parciales de Sass se utilizan con el @importar directiva.”

También eche un vistazo a estas otras publicaciones con respecto a la estructura de archivos Sass:

• Cómo estructuro mis proyectos Sass
• Estética Sass: Organización de arquitectura y estilo.
• Estructuras de directorio que te ayudan a mantener tu código

Estrategias de importación

No se puede decir lo suficiente sobre el valor de la importación y los parciales de Sass. La organización del código es clave para obtener una estructura de importación y un flujo de trabajo que simplemente funcione.

El mejor lugar para comenzar es con una hoja global que contenga importaciones, variables y combinaciones. Muchos desarrolladores prefieren separar las variables y los mixins, pero esto se reduce a la semántica..

Tenga en cuenta que los mixins son una forma de importar, o más bien duplicar, el código Sass. Son increíblemente poderosos, pero no deben usarse con “estático” código. Tenga en cuenta que hay una diferencia entre mixins, extensores y marcadores de posición, todos los cuales tienen su uso en el desarrollo de Sass..

Las mezclas se utilizan mejor con valores dinámicos pasados ​​a la mezcla para alteraciones de código. Por ejemplo, echa un vistazo a esta mezcla de Sass que crea un degradado de fondo entre dos colores.

@mixin linearGradient ($ top, $ bottom) background: $ top; / * Navegadores antiguos * / fondo: -moz-linear-gradient (top, $ top 0%, $ bottom 100%); / * FF3.6 + * / background: -webkit-gradient (linear, left top, left inferior, color-stop (0%, $ top), color-stop (100%, $ bottom)); / * Chrome, Safari4 + * / background: -webkit-linear-gradient (top, $ top 0%, $ bottom 100%); / * Chrome10 +, Safari5.1 + * / background: -o-gradiente lineal (superior, $ superior 0%, $ inferior 100%); / * Opera 11.10+ * / background: -ms-linear-gradient (top, $ top 0%, $ bottom 100%); / * IE10 + * / background: gradiente lineal (hacia abajo, $ 0% superior, $ 100% inferior); / * W3C * / filter: progid: DXImageTransform.Microsoft.gradient (startColorstr = "# ffffff", endColorstr = "# 000000", GradientType = 0); / * IE6-9 * /

La mezcla toma dos valores: un color superior y un color inferior. Puede escribir diferentes tipos de mezcla para diferentes tipos de gradientes que incluyen 3 o 4 colores diferentes. Esto le permite importar y clonar el código mixin mientras cambia los parámetros para las opciones personalizadas.

El ejemplo de Code Responsible se ve así:

.botón @include linearGradient (#cccccc, # 666666); 

Relacionado con el mixin está el marcador de posición de Sass, que es principalmente útil con la directiva extend. Es ciertamente más complejo que los mixins, pero esta puede ser una manera de Combina selectores juntos sin reescribir el código sobrante..

Si bien Sass solo tiene un método @import, he incluido mixins y marcadores de posición para demostrar la flexibilidad del código que se puede escribir en un archivo pero se puede incluir en cualquier lugar.

Al crear una estructura de importación, recuerde seguir los conceptos de la codificación DRY (No se repita).

Convenciones de nombres

Las reglas generales para las convenciones de nomenclatura se aplican a variables, funciones y combinaciones. Al nombrar algo en Sass se recomienda Usa todas las letras minúsculas con guiones para la separación..

La sintaxis del código Sass se basa realmente en el conjunto de reglas de las directrices de CSS. Estas son algunas de las mejores prácticas recomendadas para tener en cuenta:

• Dos (2) espacios de sangría, sin pestañas.
• Idealmente, líneas de 80 caracteres de ancho o menos.
• uso significativo del espacio en blanco
• usar comentarios para explicar las operaciones CSS

Estos no son elementos necesarios para el código Sass válido. Pero estas sugerencias provienen de desarrolladores profesionales que Han encontrado que estos conjuntos de reglas proporcionan la experiencia de codificación más uniforme..

Pero en lo que respecta a las convenciones de nombres, puede terminar con dos estructuras diferentes: una para los nombres Sass y otra para los nombres de clase CSS. Algunos desarrolladores prefieren BEM sobre las sugerencias de Sass. Ninguno de los dos es más o menos correcto; Simplemente diferente con diferentes procedimientos operativos.

El problema es que BEM no se traslada bien a las variables Sass o mixins porque no tienen la estructura de bloque / elemento / modificador (BEM). Personalmente prefiero usar las convenciones de nomenclatura de Sass, pero puedes probar cualquier cosa, desde camelCase hasta tu propia sintaxis interna.

Al organizar tus variables y mixins se recomienda divídalos por categoría, luego enumérelos en orden alfabético. Esto hace que la edición sea mucho más fácil porque sabes exactamente dónde encontrar algo.

Por ejemplo, para cambiar el color de un enlace, abriría su archivo de variables (tal vez _variables.scss) y localice la sección de variables de color. Luego busque el enlace por nombre (enlace de encabezado, enlace de texto, etc.) y actualice el color. Sencillo!

Para tener una idea de cómo podría estructurar una tabla de contenido para sus archivos Sass, consulte el archivo de configuración de Foundation.

 // Fundación para la configuración de sitios // ----------------------------- // // Tabla de contenido: // // 1 . Global // 2. Puntos de interrupción // 3. La cuadrícula // 4. Tipografía base // 5. Ayudantes de tipografía ... // 1. Global // --------- $ global-font-size: 100 %; $ global-width: rem-calc (1200); $ global-lineheight: 1.5; // etc

Otra práctica de nombrar pertenece a puntos de ruptura de respuesta. Al nombrar los puntos de interrupción de Sass, intente evitar nombres específicos del dispositivo. Es mejor escribir nombres como small, med, lg y xlg porque son en relación unos con otros.

Esto es mejor para las relaciones internas entre puntos de interrupción, pero también es ideal para equipos donde los desarrolladores pueden no saber qué dispositivos se relacionan entre sí..

En cuanto a en realidad poner nombres, se recomienda que Sea lo más específico posible sin variables extra largas.. Debieras Adopte convenciones de nomenclatura en todo el sitio que sean fáciles de recordar. mientras se codifica.

Proporcione convenciones de nomenclatura específicas para todo, como colores, márgenes, pilas de fuentes y alturas de línea. No solo se pueden recordar rápidamente los nombres, sino facilita su trabajo al escribir nuevos nombres de variables que deben coincidir con una sintaxis existente.

Pero hay un delgada línea entre especificidad y convolución. La práctica te ayudará a encontrar esa línea, y escribir nombres más memorables hace que sea más fácil copiar el código en otros proyectos.

Anidando y buceando

Estas dos técnicas de Sass son muy diferentes en acción, pero ambas tienen la Capacidad de ser abusado si no se usa de manera considerada..

Anidamiento es el proceso de agregando selectores anidados juntos a través de la sangría para crear más especificidad con menos código. Sass tiene una guía de anidamiento que ilustra ejemplos de anidamiento de código en acción. Pero es fácil dejarse llevar por la anidación. Si eres demasiado entusiasta, puedes terminar con un código que se ve así:

body div.content div.container … body div.content div.container div.articles … body div.content div.container div.articles> div.post … 

Demasiado específico y casi imposible de sobrescribir, este tipo de código anula el propósito de las hojas de estilo en cascada.

Si analiza esta guía de SitePoint, encontrará tres reglas de oro para anidar:

• Nunca profundices más de 3 niveles.
• Asegúrese de que la salida CSS sea limpia y reutilizable.
• Use el anidamiento cuando tenga sentido, no como una opción predeterminada.

El desarrollador Josh Broton sugiere anidar cuando sea necesario, sangra el resto como una regla general de sintaxis.

La sangría de sus selectores no causará ningún efecto CSS en cascada. Sin embargo, le resultará más fácil filtrar el archivo Sass y señalar qué clases se relacionan entre sí..

Los bucles también pueden ser usado en exceso si no se aplica correctamente. Los tres bucles Sass son @para, @mientras, y @cada. No voy a entrar en detalles sobre cómo funcionan todos, pero si estás interesado, consulta esta publicación..

En su lugar me gustaría cubrir el propósito para usar bucles y como funcionan en Sass. Deben utilizarse para ahorrar tiempo al escribir código que puede automatizarse. Por ejemplo, aquí hay un fragmento de código de la publicación de Clubmate que muestra un código Sass seguido de la salida:

/ * Código Sass * / @for $ i de 1 a 8 $ ancho: porcentaje (1 / $ i) .col - # $ i ancho: $ ancho;  / * salida * / .col-1 ancho: 100%; .col-2 ancho: 50%; .col-3 ancho: 33.333%; .col-4 ancho: 25%;  .col-5 ancho: 20%; .col-6 ancho: 16.666%; .col-7 ancho: 14.285%; .col-8 ancho: 12.5%;

Estas clases de columna se pueden utilizar junto con un sistema de cuadrícula. Incluso podría agregar más columnas o eliminar algunas simplemente editando el código de bucle.

Bucles debería no ser usado para duplicar selectores o propiedades para un selector; para eso están los mixins.

Además, cuando se realiza un bucle, hay algo que se llama mapas Sass que almacenan pares de datos clave-valor. Los usuarios avanzados deben aprovechar estos siempre que sea posible.

Pero los bucles Sass regulares son simples y efectivos para proporcionar salida de código sin repetición. La mejor razón para usar bucles es con Propiedades CSS que varían la salida de datos..

Aquí hay una buena manera de comprobar si su bucle es útil: pregúntese Si hay alguna otra forma de generar el CSS que necesita con menos líneas de código. Si no, entonces la sintaxis del bucle es probablemente una gran idea..

Si alguna vez está confundido o desea comentarios sobre los nidos o los bucles Sass, debe publicar una pregunta en / r / sass / or / r / css /, comunidades Reddit activas con desarrolladores de Sass muy informados.

Modularización

La práctica de escribir Sass modular es una necesidad absoluta para la mayoría de los proyectos (yo diría, cada proyecto). La modularización es el proceso de Desglosando un proyecto en módulos más pequeños. Esto se puede lograr en Sass usando parciales.

La idea detrás de Sass modular es escribir archivos SCSS individuales con un propósito específico orientado a contenido global (tipografía, cuadrículas) o elementos de página (pestañas, formularios).

La definición del módulo Sass es bastante clara y hace una sugerencia muy específica: importar un módulo nunca debe generar código.

La idea de una salida obligatoria para todos los módulos sería una pesadilla para la optimización. En su lugar, debe crear módulos individualmente y solo llama a los que necesites. Los módulos se pueden definir por combinaciones o funciones, pero también es posible crear módulos que contengan selectores.

Sin embargo, un artículo de Sass Way sugiere escribir todos los selectores como mixins y solo llamarlos cuando sea necesario. Si usted adopta esto o no es, en última instancia, su elección. Creo que depende del tamaño del proyecto y su comodidad con el manejo de mezclas..

Citando a John Long de su post en The Sass Way:

“Para mí, los módulos se han convertido en las unidades básicas o bloques de construcción de mis proyectos Sass.”

Si realmente estás buscando una rutina Sass, te recomiendo que vayas completamente modular. Intente construir casi todo como un parcial modular que se incluye en un archivo CSS primario. Al principio, este flujo de trabajo puede parecer desalentador, pero tiene sentido en una escala más grande, especialmente con proyectos grandes.

Además, es mucho más fácil copiar módulos de un proyecto a otro cuando están ubicados en archivos separados. Flexibilidad y código reutilizable Son los pilares del desarrollo modular..

Para obtener más información sobre los módulos de Sass y las técnicas de modularización, consulte estas publicaciones:

• Módulos CSS: Bienvenido al futuro
• Los pros y los contras de Sass modular
• Organización CSS modular con SMACSS y SASS

Encuentra tu flujo de trabajo perfecto

Cada equipo y desarrollador individual tiene sus propias prácticas que funcionan mejor. Debe adoptar prácticas que funcionen mejor para usted personalmente, o elegir adoptar las que mejor funcionen para su equipo profesionalmente.

También considere usar Gulp o Grunt para la automatización de proyectos y para minimizar su código. Esto ahorrará una gran cantidad de mano de obra y las herramientas de automatización ahora son, sin duda, parte de las mejores prácticas para el desarrollo moderno de frontend..

Hojee bibliotecas de código abierto como SCSS de Foundation en GitHub para aprender más sobre las mejores prácticas empleadas por otras bibliotecas.

Lo mejor de las mejores prácticas es que realmente mejoran su trabajo la mayor parte del tiempo, pero hay muchas alternativas. Solo prueba cosas y mira como se sienten. Siempre aprenderá, por lo que sus mejores prácticas pueden cambiar rápidamente en el transcurso de 5 años.

Una sugerencia final que tengo para todo el proceso de Sass es tomar decisiones teniendo en cuenta la claridad. Escribe código que facilite tu trabajo.. No complique en exceso un proyecto si hay una forma más sencilla de hacerlo.

Sass está destinado a mejorar la experiencia de desarrollo de CSS, por lo que Trabajar con claridad y mejores prácticas. para obtener la mejor experiencia posible.

Envolver

La congestión en un flujo de trabajo Sass se puede corregir mediante la modificación de los estilos de código y siguiendo las mejores prácticas. He descrito algunas sugerencias en esta publicación de los blogs y desarrolladores profesionales de Sass..

La mejor manera de aprender más es aplicar estas prácticas en su flujo de trabajo y ver que funciona. Con el tiempo, encontrará que algunas actividades son más beneficiosas que otras, en cuyo caso usted debería mantener lo que funciona y dejar lo que no.

Vea estos enlaces para encontrar más consejos y mejores prácticas para el desarrollo de Sass:

• Pautas Sass
• Una visión para nuestro sass
• 8 consejos para ayudarte a obtener lo mejor de Sass
• Extendiendo en Sass sin crear un desastre
• Sass Best Practices - Anidando más de 3 niveles de profundidad