Como lo estás leyendo, el clean code en maquetación no existe. Todavía no hay ningún gurú que establezca unas reglas básicas para crear una maquetación limpia y fácil de mantener… hasta ahora.
‘’El albañil de la web’’, término que utilicé hace años y que sigo manteniendo por la similitud que tiene esta profesión con la nuestra. Hay que crear unos buenos cimientos para que a posteriori no salgan a la luz desperfectos como goteras, marcos de puerta desniveladas, puntos de luz mal puestos, etc… Todo esto lo podemos trasladar a la maquetación. Debemos crear desde el inicio correctamente esos cimientos, para que a la hora de introducir la lógica front, no se nos descuadren los componentes después de maquetarlo aunque siempre haya excepciones.
Como buenos “albañiles” tenemos nuestras propias herramientas con las que podremos desempeñar nuestro trabajo. Hay algunos que utilizan otras herramientas, pero vamos con las nuestras tomando la base de un proyecto en Angular:
Componentes
Para nuestra maquetación vamos a crear pequeños componentes de forma que sea posible reutilizarlos, por ejemplo, para crear tabla-paginada debemos de crear un único componente tabla-paginada ya que este contiene toda la maquetación necesaria para mostrar los datos en sus respectivas columnas, filas y celdas junto con sus botones de paginación. La información suministrada a este componente tiene ser dinámica, sin saber el número de filas o columnas tiene la tabla. Si realizamos una correcta maquetación sabremos que los datos se mostrarán como queremos independientemente del tipo de dato.
Bootstrap u otros frameworks
A la hora de maquetar debemos utilizar componentes que nos brinde los frameworks. No hace falta inventar la rueda, ya que estos componentes facilitan la implementación de la lógica front. A no ser que por especificaciones haya que crear un componente especial que no pertenezca al framework.
También debemos usar sus clases para aplicar estilos de márgenes, padding, tamaños de fuente, colores de texto, etc. No importa las clases anidadas que pongamos siempre y cuando alcancemos el objetivo visual que buscamos.
Otra de las ventajas de las que nos podemos beneficiar es que ofrecen una template con su esquema de colores, iconos, tamaños de texto, etc… Para poder sobrescribir estos estilos podemos crear un archivo scss llamado variable.scss en la que vamos a utilizar el nombre de la variable que usa el framework para darle un nuevo valor adaptado a nuestro diseño.
Preprocesadores
Aunque en Angular SASS ya viene por defecto se tiende a olvidar que en los ficheros scss se puede y se debe utilizar este “lenguaje”. Hace que la anidación de clases sea mucho más rápida y sencilla que ya no hace falta repetir toda la declaración de clases con sus respetivos niveles de profundidad.
nav {
ul {
margin: 0;
padding: 0;
list-style: none;
}
li { display: inline-block; }
a {
display: block;
padding: 6px 12px;
text-decoration: none;
}
}
Spinal-case
Dejamos atrás la nomenclatura camelCase, que en muchas ocasiones es confuso distinguir, para pasar a utilizar spinal-case. Mejora la visibilidad de la declaración de la clase y su función, por ejemplo, class="tabla tabla-paginada". Podemos utilizar "tabla paginada" pero necesitamos crear clases que definan claramente su función.
Aunque los frameworks sigan utilizando camelCase nosotros vamos a utilizar nuestras propias "herramientas".
BEM
BEM (Bloque, elemento y modificador) es una metodología que consiste en crear componentes reutilizables y escalables.
Bloques
Los bloques son todas aquellas etiquetas que encapsulan toda la estructura del componente (header, div, article, section, etc…)
El bloque de elementos corresponde a la raíz de la clase y deberá ir siempre primero. Cuando ya está definido es posible nombrar los elementos que compondrán la estructura final y su contenido.
<nav class=’topmenu’>
<!— Bloque ->
</nav>
Elementos
Los elementos componen la estructura del bloque (p, button, figure, a, etc..)
<nav class=’topmenu’>
<a class=’topmenu__link’>
<!- Elemento ->
</a>
</nav>
Modificadores
Estos se usan agregando un doble guión justo después del elemento o bloque que se quiere modificar.
<nav class=’topmenu’>
<a class=’topmenu__link--activo’>
<!- Elemento ->
</a>
</nav>
BEM con SASS
.topmenu {
&__link {
display: block;
color: #000;
&--activo {
color: #ca0023
}
}
}
Conociendo y aplicando la metodología BEM en tus proyectos SASS y CSS te permitirá aumentar la productividad de tu equipo de trabajo y ser más eficiente.
Atributos de etiquetas
Usar atributos de etiquetas de html es bueno. Un [disabled] no hace daño a nadie, pero no hay que abusar. Debemos usar las clases lo máximo posible y solo usar los atributos que puedan cambiar el estado de la etiqueta.
EM
Dentro de los tamaños de fuente, la unidad absoluta por defecto es el píxel (px), y las unidades relativas son em, rem y el porcentaje. En nuestro caso nos quedamos con em al ser mucho más “responsive”.
Las dimensiones de los elementos cambian junto al tamaño de la fuente, es mucho más fácil de mantener utilizando unidades relativas, sobre todo en diseño responsive.
Si cambiamos el font-size de un elemento superior en un determinado breakpoint de mediaqueries, el tamaño de todos los elementos inferiores se actualizará automáticamente. Por el contrario, si se utilizan unidades absolutas, hay que actualizar el tamaño de todos los elementos en cada breakpoint.
Por defecto el tamaño que establece el navegador desde la etiqueta <html> es un Font-size del 100% lo que equivale a 16px o lo que es mismo 1em. Aquí viene un pequeño truco para hacer el calculo de em más sencillo.
Se puede establecer un Font-size sobre la etiqueta <html> a un 62.5%. para que el tamaño sea a 10px y así hacer mejor los cálculos con múltiplos de 10 haciéndolo más simple la declaración de Font-size de los elementos inferiores, por ejemplo:
html {
Font-size: 62.5% (10px)
}
p {
Font-size: 1.2em (12px)
}
Flex
Display: flex… Una propiedad muy potente que nos permite alinear vertical y horizontalmente cualquier elemento inferior. Con esta propiedad el float carece de sentido ya que flex es mucho más versátil y se adapta mejor a los diseños responsive.
Y con estas herramientas podemos empezar a crear los cimientos de nuestra aplicación para que sea lo más responsive, mantenible, reutilizable y accesible para alguien que entre nuevo en el proyecto le sea mucho más sencillo entender la maquetación.
Conclusiones
En definitiva, si te interesa todo lo que tenga que ver con el clean code, te animamos a leer alguno de los artículos relacionados con esta temática:
- Aplicando Code Review en Dev&Del
- Clean Code. Cleaning the code
- Cleaning the code: Nomenclatura o la importancia de llamarse Ernesto
- Cleaning the Code: Introducción al testing
- PhpUnit con tu tema de WordPress
- isPlatformBrowser como principio de responsabilidad ¿doble?
- 10 consejos para aplicar Clean code en SQL