Desde las primeras líneas de código, cada persona comienza a comprender la importancia de organizarlo correctamente y optimizar el espacio de trabajo en su conjunto.
No es importante de qué industria hablar específicamente, pero es importante entender que donde sea que haya código, debe haber reglas para su creación y almacenamiento.
En la primera pareja, por supuesto, puede parecer que cumplir ciertas reglas y órdenes solo lleva tiempo, lo que en la práctica parece completamente diferente. La quintaesencia de cualquier principio de escribir código es que no lo escribimos de una vez por todas; constantemente volvemos a él con el propósito de editarlo y modificarlo.
Este proceso puede convertirse en un problema real si el caos y la imprevisibilidad reinan allí. Este problema puede agravarse si este caos no fue creado por usted, sino por una persona con la que no es posible establecer contacto. Es para eliminar tales situaciones que existen metodologías.
Si hablamos de CSS, entonces podemos decir con confianza: cada uno de nosotros utiliza una determinada metodología, consciente o no. Incluso si una persona no usa ciertas reglas y estándares, entonces todavía tiene sus propios hábitos y constantemente repite trucos.
Las formas de escribir código no tienen que ser generalmente aceptadas y estandarizadas, algo más debe ser obligatorio: deben ser predecibles.
La lista de metodologías a las que debe prestar atención no es tan larga:
-BEM,
-Smacss,
-OOCSS,
-MCSS,
CSS CSS
El CSS atómico es quizás la metodología más inusual e incluso algo aterradora, que afortunadamente no evita que sea muy comprensible y predecible.
Para corroborar mi elección, tengo que retroceder un poco.
CSS casi atómico
Hubo momentos en que el directorio raíz de la abrumadora cantidad de proyectos en la etapa de creación de la interfaz parecía tres archivos y dos carpetas:
>fonts >img -index.html -style.css -script.js
Pero esta simplicidad puede parecer engañosamente conveniente, de hecho, al menos en dos de estos tres archivos estaba sucediendo algo terrible.
Siempre me molestaron dos cosas: desorden y falta de estilo. En Css, muchos matices diferentes caen bajo la clasificación de trastorno, pero sobre todo no estaba contento con la repetición constante de las mismas reglas y propiedades para diferentes selectores.
La primera solución a este problema fue la siguiente:
- creando un archivo llamado "re-use.css",
- creación de instrucciones en este archivo, que en teoría puede ser necesario para más de un selector,
- agregando diferentes selectores a la misma instrucción.
Se veía así:
... .class { display: inline-block;} .class { text-transform: uppercase;} ...
y posteriormente aceptó lo siguiente:
... .menu-link, .primary-button, .form-button, .footer-link, .social-link { display: inline-block;} ...
Por supuesto, esta solución fue muy inconveniente y afortunadamente temporal. No mucho tiempo atormentado con el cambio interminable entre archivos, y al encontrar el lugar correcto en ellos, llegué a la conclusión de que sería mucho más conveniente crear clases separadas que sean responsables de una instrucción cada una:
...
.inline-block { display: inline-block;} .block {display: block;} .uppercase {text-transform: uppercase;}
En los archivos html, las etiquetas con una gran cantidad de clases parecían extrañas, pero esta solución me pareció bastante aceptable:
<aside class=”sidebar fixed left top w-30 h-100 main-fill”></aside>
De un vistazo, es suficiente entender que se trata de una columna lateral, con posicionamiento fijo, en el lado izquierdo de la pantalla, que ocupa el 30% de su ancho y el 100% de su altura, llena del color principal.
Todo lo relacionado con los valores numéricos, principalmente estos fueron sangrías externas e internas, escribí en el formato estándar. Para hacer esto, agregué una clase separada que viene primero a cada etiqueta, o grupo de etiquetas, en el ejemplo anterior es la clase de "control deslizante".
Fue un enfoque casi atómico y casi conveniente. Varias deficiencias le impidieron sentirse cómodo, la más importante de las cuales fueron las siguientes situaciones:
- al crear una gran cantidad de etiquetas similares, por ejemplo, elementos de la lista, tuve que copiar muchas clases y parecía engorroso,
- al realizar cualquier cambio, tuve que eliminar y agregar clases para cada elemento por separado,
- había muchas clases no utilizadas que eran difíciles de atrapar.
Y luego dos cosas vinieron al rescate que ayudaron a resolver todos los problemas: este es el preprocesador y el motor de plantillas.
Con su ayuda, modifiqué mi metodología e hice que el diseño fuera agradable y conveniente.
Css casi perfecto
Comenzaré con el preprocesador. Su elección no es fundamental, primero usé Sass, luego SCSS y finalmente cambié a Stylus, porque respeto el minimalismo, y Stylus fue lo más minimalista posible (scss se usará en los ejemplos a continuación, debido a su popularidad).
Entonces, lo primero que hice fue escribir clases adicionales que parecían átomos reales usando la directiva @extend:
.flex { display: flex; flex-wrap: no-wrap; } .flex-jc-center { @extend .flex; justify-content: center; } .flex-ai-center { @extend .flex; align-items: center; }
Me gustó la idea, y la directiva @extend causó un parecido con el núcleo atómico, al lado del cual había instrucciones adicionales.
Decidí que la idea debería desarrollarse y creé un archivo separado para los organismos. Organismos que llamé clases que incluyen varias directivas @extend:
.header { @extend .fixed; @extend .w-100; @extend .main-fill; @extend .left; @extend .top; @extend .flex-ai-center; @extend .z-top; }
Después de crear un pequeño "zoológico" a partir de varios organismos, decidí hacer algo con las clases que requieren valores numéricos para la sangría y el tamaño.
Las capacidades del preprocesador me ayudaron a enfrentar esto nuevamente, con la ayuda de la cual escribí algunas funciones y agregué variables.
Primero, estudié en detalle los proyectos gráficos que obtengo de los diseñadores y revelé una serie de patrones:
- cantidad de colores para cada proyecto,
- cantidad de fuentes
- cantidad de diferentes tamaños para texto y encabezados,
- sangría repetida (para secciones, botones, etc.)
El primer paso fue escribir funciones y mixins para crear las clases necesarias:
// px em @function em($pixels, $context: $browser-context) { @return #{$pixels/$context}em };
// $text-size: ( l: 18, m: 16, s: 14, xs: 12 );
@mixin emFonts($list, $n) { // $list – , n – . @each $status, $size in $list { // - &-#{$status} { font-size: em($size - $n); // } } }
Ahora podemos llamar a esta combinación de mixins y funciones en cualquier lugar conveniente para nosotros:
.txt { @include emFonts($text-size, 0) }
Y en la salida obtenemos 4 clases para texto de diferentes tamaños:
.txt-m { font-size: 1.125em; } .txt-s { font-size: 1em; }
Del mismo modo, se crean y se llaman funciones para tamaños de encabezado, colores de texto y relleno, fuentes, etc.
Es decir, el trabajo en cada proyecto comienza con el llenado de los valores para las variables, y las clases y funciones mismas migran de un proyecto a otro.
Motor de plantillas.
Creo que muchos de ustedes usan plantillas, y lo más probable es que sea Pug (anteriormente llamado Jade).
Para la composición atómica, es necesario gracias a 3 cosas:
Pug nos salva por completo de las engorrosas microclases de código HTML, ya que podemos activar el siguiente código:
… <ul class=”menu__list flex-ai-center w-100 relative “> <li class=”menu__item m-color m-font txt-s inline-block bold-border”>first</li> <li class=”menu__item m-color m-font txt-s inline-block bold-border”>second</li> <li class=”menu__item m-color m-font txt-s inline-block bold-border”>third</li> </ul>
conveniente para editar:
-let menuItemClasses = 'menu__item m-color m-font txt-s inline-block bold-border' // ul li(class=`${menuItemCLasses}`) frst li(class=`${menuItemCLasses}`) second li(class=`${menuItemCLasses}`) third ... </ul>
o en otra realización, usando un bucle:
let menuItems = ['first', 'second', 'third'] ul -for(let item of menuItems) { li(class=”menu__item m-color m-font txt-s inline-block bold-border”) -}
Esto no es menos conveniente, porque la línea con las clases necesarias no se repite más de una vez.
La última vulnerabilidad de esta metodología fue que una gran cantidad de clases no utilizadas permanecieron en el código. Pero este problema aparentemente grave se resolvió fácilmente agregando complementos al generador de proyectos que eliminan clases innecesarias.
Conclusión
En conclusión, me gustaría decir lo siguiente:
Antes de comenzar a usar la "metodología casi atómica", usé smacss y luego BEM durante mucho tiempo. Como resultado, desde bem dejé solo los nombres de las clases que requieren descripciones de sangrías y tamaños, y la jerarquía de almacenamiento de archivos y carpetas. Un conjunto de clases y funciones listas para usar, me conecto al proyecto como una biblioteca.
Un punto importante que me gustaría señalar es la conveniencia del diseño de las páginas y sus secciones individuales en su conjunto. Gracias a las microclases, es bastante fácil crear un "esqueleto" de una página o sección en el motor de plantillas y solo luego escribir estilos para ello.