Atomic Design - это методология, описывающая структуру кода для таблиц стилей. Но мне кажется, что соглашения по именованию там иногда могут быть неоднозначными. Что такое молекула? Что такое организм? Как мы узнаем, где провести границу между ними? Эти конкретные вопросы, кажется, являются самым большим камнем преткновения для интерпретации атомной архитектуры.

Сегодня мы обсудим, что я использую, конкретные аспекты соглашений об атомном дизайне, с которыми я борюсь, что я сделал для решения моих проблем, и как я в настоящее время организую использование Sass, например, шаблон 7-1.

Атомная структура

«Мы не разрабатываем страницы, мы проектируем системы компонентов» - Стивен Hay

Мне нравится дизайн атома и его идеологии, но я обнаружил, что они могут разрушиться при работе с членами команды, которые плохо знакомы с тем, как все это работает. В прошлом я использовал следующую структуру папок:

Организация папок: root/css/src/

 - vars
 - functions
 - mixins
 - base
 - plugins
 - typography
 - atoms
 - molecules
 - organisms
 - templates
 - pages
 - states
 - utility
 style.scss

Внутри style.scss частичные Sass импортируются с использованием gulp-sass-glob-import:

Файл индекса импорта Sass: root/css/src/style.scss

// Config
@import "vars/*";
@import "functions/*";
@import "mixins/*";

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

// General DOM selector styles
@import "base/*";

// Fonts & General Type Styling
@import "typography/*";

// 3rd Party Addons
@import "plugins/*";

// Atomic Design
@import "atoms/**/*";
@import "molecules/**/*";
@import "organisms/**/*";
@import "templates/**/*";
@import "pages/**/*";

// Variations thru Events
@import "states/*";

// General UI Helpers
@import "utility/*";

Порядок с этой настройкой имеет значение. Если нужно «подстроить» атом, молекулу или организм, декларации, сделанные в шаблонах или на страницах, то они будут отменять вышеупомянутые части вместе с любыми другими частичными предшествующими.

Кроме того, порядок позволяет переопределять стили плагина, если это потребуется (обычно на моем опыте это и происходит).

Содержание каталога

Большая часть содержимого для каждого атомарного каталога (атомы, молекулы, организмы, шаблоны, страницы) будет содержать частичные выражения, теоретически легко обнаруживаемые и легко управляемые в случае необходимости.

 - atoms
   - _buttons.scss
   - _links.scss
   - _inputs.scss
 - molecules
   - _navigation.scss
   - _search-form.scss
   - _contact-form.scss
 - organisms
   - _header.scss
   - _footer.scss
   - _content.scss
 - templates
   - _sticky-footer.scss
   - _grid-2column.scss
   - _grid-3column.scss
 - pages
   - _home.scss
   - _about.scss
   - _contact.scss

Организация представляется разумной, если вы разбираетесь в Atomic Design, но не подходит для тех, кто незнаком с подходом и методолигией. Разработчик, не знающий Atomic Design, не будет понимать, что поисковая форма находится в каталоге molecules,  и может начинать поиск в других областях для внесения изменений или просто разочаровываться и создавать новый файл; Я видел, как такое происходило.

Структура компонентов

На момент написания этой статьи я принимаю подход, рассматривающий элементы полностью как компоненты, такие как блоки lego, тем самым создавая простоту использования для всех, кто связан с кодовой базой. Взгляните на следующую структуру каталогов:

 - vars
 - functions
 - mixins
 - base
 - typography
 - plugins
 - toolbox
 - components
 - layout
 - pages
 - states
 - utility
 style.scss

Надеюсь, вы можете увидеть на этом примере, что достаточно интуитивно собрать цель каждой папки (за исключением панели инструментов). «Панель инструментов» - это место для хранения помощников, таких как пользовательские классы для макетов и шаблонов объектов, анимации пользовательских ключевых кадров и т.д. Эти элементы панели инструментов для меня обычно заканчиваются как части, которые я могу переопределить в будущем, и почему они импортируются перед каталогом компонентов.

На этом этапе partials загружаются в индекс стилей следующим образом:

// Config
@import "vars/**/**";
@import "functions/*";
@import "mixins/*";

// UI
@import "../bower_components/normalize-scss/_normalize";
@import "base/*"; // general styling using DOM element selectors
@import "typography/*";
@import "plugins/**/*"; // 3rd party add-ons
@import "toolbox/**/*"; // Non-Utility Helpers
@import "components/**/*"; // lego blocks
@import "layout/**/*";
@import "pages/**/*";
@import "states/**/*";
@import "utility/**/*";

«Компоненты» будут содержать части пользовательского интерфейса, такие как кнопки, входы, логотипы, аватары, верхний колонтитул, нижний колонтитул, формы и даже такие модули, как навигация. Компоненты могут быть любыми, если только они делают одно и только одно, многократно используются, повторно используются в проекте и, самое главное, независимы; Не плохое определение, которое будет понято повсеместно, если вы спросите меня. Этот конкретный подход также реализует различные идеи от SMACSS (состояний) и Atomic Design (шаблоны - называемые макетами в этом примере - и страницы).

С точки зрения нахождения намного проще найти каталог компонентов и найти коррелирующую часть интерфейса, которую разработчик может отслеживать; например:

 - components
   - _buttons.scss
   - _navigation.scss
   - _masthead.scss
   - _footer.scss
   - _logo.scss
   - _avatar.scss
   - _contact-form.scss
   - _sales-calculator.scss

По существу, компоненты - это универсальный магазин. Атомный дизайн может отлично работать для команды из одного человека или даже команды, которая хорошо знакома в методологией атомного дизайна, но в большой команде вы можете встретить разочарование.

Вывод

Atomic Design определено можно использовать, чтобы сохранить ваш стиль элементов минимальным, для того чтобы можно было создавать значимые и многоразовые компоненты интерфейса. Но некоторые аспекты для вас могут оказаться запутанными. Определите для себя, что лучше всего подходит для вас, и сделайте выводы из этого. Но помните, что это то только мой опыт, и у других может быть другая позиция.

Мне очень хотелось бы услышать, как вы сами подходите к этому сценарию, поэтому дайте мне знать в комментариях. Счастливого всем кодирования!