La estructuración Sass: Di adiós a la ambigüedad del diseño atómico.

El diseño atómico es una metodología que describe la estructura de código sensible para las hojas de estilo. Tiene muchos seguidores, pero me parece que sus convenciones de nombres a veces pueden ser ambiguas. ¿Qué es una molécula? ¿Qué es un organismo? ¿Cómo sabemos dónde trazar la línea entre los dos? Estas preguntas particulares parecen ser el mayor obstáculo para interpretar una arquitectura atómica.

Hoy discutiremos lo que utilizo, las facetas particulares de las convenciones de diseño atómico con las que tengo problemas, lo que he hecho para resolver mis problemas y cómo organizo actualmente Sass utilizando, por ejemplo, el patrón 7-1.

Estructura atómica

"No estamos diseñando páginas, estamos diseñando sistemas de componentes". - Stephen Hay

Me encanta el diseño atómico y sus ideologías, pero descubrí que pueden colapsar cuando se trabaja con miembros del equipo que no están íntimamente familiarizados con cómo funciona todo. En el pasado usé la siguiente estructura de carpetas:

Organización de carpetas: root/css/src/

1

 - vars

2

 - functions

3

 - mixins

4

 - base

5

 - plugins

6

 - typography

7

 - atoms

8

 - molecules

9

 - organisms

10

 - templates

11

 - pages

12

 - states

13

 - utility

14

 style.scss

Dentro de style.scss los parciales de Sass se importan usando gulp-sass-glob-import:

Archivo de índice de importación de Sass: root/css/src/style.scss

1

// Config

2

@import "vars/*";

3

@import "functions/*";

4

@import "mixins/*";

5

6

// Bower Components

7

@import "../bower_components/normalize-scss/_normalize";

8

9

// General DOM selector styles

10

@import "base/*";

11

12

// Fonts & General Type Styling

13

@import "typography/*";

14

15

// 3rd Party Addons

16

@import "plugins/*";

17

18

// Atomic Design

19

@import "atoms/**/*";

20

@import "molecules/**/*";

21

@import "organisms/**/*";

22

@import "templates/**/*";

23

@import "pages/**/*";

24

25

// Variations thru Events

26

@import "states/*";

27

28

// General UI Helpers

29

@import "utility/*";

El orden con esta configuración importa un poco. Si es necesario ajustar un “átomo”, una “molécula” u “organismo”, las declaraciones hechas en plantillas o páginas anularán las partes mencionadas anteriormente, junto con cualquier otro parcial anterior.

La orden además habilita anulaciones al estilo de un complemento, en caso de que sea necesario (y generalmente lo hace en mi experiencia).

Contenidos del directorio

Gran parte de los contenidos para cada directorio atómico (átomos, moléculas, organismos, plantillas, páginas) contendrán parciales que, en teoría, son fáciles de encontrar y fáciles de administrar cuando sea necesario.

1

 - atoms

2

   - _buttons.scss

3

   - _links.scss

4

   - _inputs.scss

5

 - molecules

6

   - _navigation.scss

7

   - _search-form.scss

8

   - _contact-form.scss

9

 - organisms

10

   - _header.scss

11

   - _footer.scss

12

   - _content.scss

13

 - templates

14

   - _sticky-footer.scss

15

   - _grid-2column.scss

16

   - _grid-3column.scss

17

 - pages

18

   - _home.scss

19

   - _about.scss

20

   - _contact.scss

La organización parece sensata si eres sabio con respecto al diseño atómico, pero se queda corto para alguien que no está familiarizado con el enfoque y la nomenclatura. Un desarrollador que no esté al tanto del Diseño Atómico no entenderá el hecho de que una forma de búsqueda reside en el directorio molecules, y puede iniciar la búsqueda en otras áreas para realizar ediciones, o simplemente frustrarse y crear un nuevo archivo; lo he visto suceder.

Una estructura de componentes

En el momento de escribir este artículo, adopto un enfoque que contempla elementos como componentes, como bloques lego, creando así una facilidad de uso para todos los involucrados en el código base. Echa un vistazo a la siguiente estructura de directorios:

1

 - vars

2

 - functions

3

 - mixins

4

 - base

5

 - typography

6

 - plugins

7

 - toolbox

8

 - components

9

 - layout

10

 - pages

11

 - states

12

 - utility

13

 style.scss

Espero que puedas ver en este ejemplo que es bastante intuitivo reunir el propósito de cada carpeta (con la excepción de la caja de herramientas). "Caja de herramientas" es un lugar para almacenar ayudantes no relacionados con las utilidades, como clases personalizadas para diseños y patrones de objetos, animaciones de fotogramas clave personalizados, etc. Estos elementos de la caja de herramientas, para mí, por lo general terminan como partes que puedo anular o desear en el futuro, y por qué se importan antes del directorio de componentes.

En esta etapa, los parciales se cargan en el índice de estilos así:

1

// Config

2

@import "vars/**/**";

3

@import "functions/*";

4

@import "mixins/*";

5

6

// UI

7

@import "../bower_components/normalize-scss/_normalize";

8

@import "base/*"; // general styling using DOM element selectors

9

@import "typography/*";

10

@import "plugins/**/*"; // 3rd party add-ons

11

@import "toolbox/**/*"; // Non-Utility Helpers

12

@import "components/**/*"; // lego blocks

13

@import "layout/**/*";

14

@import "pages/**/*";

15

@import "states/**/*";

16

@import "utility/**/*";

Los “Componentes” contendrán partes de la interfaz de usuario como botones, entradas, logotipos, avatares, encabezados, pies de página, formularios e incluso módulos como la navegación. Los componentes pueden ser cualquier cosa, siempre que hagan una cosa y solo una cosa, reutilizables, reutilizados en todo el proyecto y, lo que es más importante, independientes; no es una mala definición para ser entendida universalmente si me preguntas. Este enfoque particular también implementa varias ideas de SMACSS (estados) y Diseño atómico (plantillas, llamadas diseño en este ejemplo, y páginas).

En cuanto a la forma de encontrar, es mucho más fácil localizar el directorio de componentes y encontrar la parte de la interfaz correlativa que un desarrollador puede estar rastreando; por ejemplo:

1

 - components

2

   - _buttons.scss

3

   - _navigation.scss

4

   - _masthead.scss

5

   - _footer.scss

6

   - _logo.scss

7

   - _avatar.scss

8

   - _contact-form.scss

9

   - _sales-calculator.scss

Esencialmente, los componentes son una ventanilla única. El diseño atómico podría funcionar perfectamente para un equipo de uno, o incluso un equipo que sea íntimamente familiar, pero dentro de un equipo más grande se puede sentir la frustración.

Conclusión

El diseño atómico puede usarse absolutamente para mantener un estilo mínimo en los elementos con el fin de crear componentes de interfaz significativos y reutilizables. Pero puedes encontrar ciertos aspectos confusos. Decide por ti mismo qué funciona mejor para ti y saca conclusiones de eso. Al igual que con todo, esta es solo mi experiencia y otros pueden tener una postura diferente.

Me encantaría saber cómo abordan este escenario, así que avísenme en los comentarios. ¡Feliz codificación a todos!