Атомарный дизайн 2.0 и разработка через стайлгайд

Что такое атомарный дизайн?

В 2013 году Брэд Фрост перевернул мир проектирования веб-приложений своей статьей про атомарный дизайн. Предисловие к его статье отражает тенденцию последних лет в разработке ПО: "Мы не проектируем страницы, мы проектируем системы компонент. — Стэфен Хей".

Проектирование предполагает весь процесс создания компонент: начиная от дизайна, проходя через верстку в полную изоляцию компонент во фронтэнде. Современные js-библиотеки и фрэймворки с большим энтузиазмом воприняли эти идеи: react, angular, styled-components, bootstrap.

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

1. Атомы
2. Молекулы
3. Огранизмы
4. Шаблоны
5. Страницы

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

Что же на практике?

Вы уже пробовали применить эту методологию в своем проекте? Если нет, то вы просто обязаны это сделать! Если у вас проект на React'e, начните со стайлгайда. Опишите все компоненты-атомы: поля формы, иконки, кнопки, простые блоки, типографику: тексты, заголовки, ссылки. Далее переходите к компонентам-молекулам: формы, хлебные крошки, небольшие блоки элементов, состоящие из атомов. Справились? Переходим на следующий уровень: компоненты-организмы. Исходя из методологии атомарного дизайна - это все прочие элементы: большие и маленькие блоки, нестандартные элементы, слайдеры, шапки сайта, меню, модалки, виджеты, блоки товаров и прочее-прочее. И вот этого прочего-прочего потом оказывается так много, что этот большой набор компонент сам по себе становится эдаким монстром. И блок социальных кнопок находится на одном уровне вложенности с целым блоком шапки, содержащим и логотип, и меню, и профиль пользователя, и корзину.

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

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

Поэтому нужен ли нам темплейт? Ответ однозначно Нет.

Ну и страницы. Компонеты-страницы, представляющие как будет выглядеть собранная нами из компонент готовая для заказчика страничка.

Из химии в биологию

Как видим, на практике все гораздо сложнее. Что же делать? Прогибаться под методологию, которая, кажется, не до конца продумана? Почему бы не расширить ее своими понятиями, не подстроить ее под свои нужды?

Для начала выкинем темплейты. Без сожаления. Их никто не использует. Фьюить! Их нет.

Второе - это необходимость разбиения уровня Организмов на несколько. Все описанное далее - это мой опыт применения атомарного дизайна в реальном проекте. И придуманые мной слои отражают потребность в этих сущностях.

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

• популяции
• экосистемы

(конечно, следующие за ними компоненты-страницы звучат не очень, но они всегда выбивались из этого ряда)

Что же таят в себе новые слои?

Или как выделить их из организмов?

Для начала я выделила для себя две большие категории слоев:

1. Абстрактная - категория для сущностей, которые не привязанны к конкретной предметной области. В рамках атомарного дизайна 2.0 к ней можно отнести первые 3 слоя:
   
   • атомы
   • молекулы
   • организмы
   Они могут быть наполнены любым содержанием. Пример атома: кнопка; что она делает, за что отвечает? В самой компоненте мы этого никогда не узнаем, пока не поместим ее в какой-то контекст. Пример молекулы: блок фильтров; те же вопросы: что он фильтрует? Какие данные? В рамках этой компоненты нам это неважно, потому что на одной странице он будет фильтровать список книг, а на второй - каталог мыла для рук. Пример организма: карточка товара, в которой нам не интересен конкретный товар, мы показываем в компоненте только его фото с названием и ценой.
   
   
2. Предметная - категория компонент, которые отражают предметную область. И здесь мы уже говорим на языке заказчика по правилам DDD (Domain-driven design, или предметно-ориентированного программирования). Тут расположены следующие 3 слоя:
   
   • популяции
   • экосистемы
   • страницы
   Каждая из этих компонент имеет смысл только в рамках конкретного приложения: форма заказа товара, список платежных систем, корзина, перечень товаров. Название компоненты содержит ее область применения.

Слой популяции

Название этого слоя говорит само за себя. Популяция - это совокупность особей (организмов) одного вида.

Возьмем нашу карточку товара из примера выше. Группируя различными способами наборы этих карточек, мы получим "самые популярные товары", "товары дня", "каталог товаров", "товары со скидками". При этом они совсем не обязаны выглядеть одинаково, как набор товаров в ряд из 4 штук. Они могут быть завернуты в карусель или слайдер, иметь табличное представление или построчное. Тут уж ваш дизайнер разойдется как ему будет удобно, а разработчику не нужно будет добавлять if-условия для каждого такого представления, так как каждое из них будет самостоятельной компонентой.

Слой экосистемы

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

Так же экосистемы выполяют еще одну роль, для этого я немного забегу вперед и расскажу о страницах.

Страницы представляют собой собственно страницы. Полноценные, законченые страницы, которые состоят из других компонент. В результате разработки всех предыдущих слоев мы уже имеем достаточно много кусочков, из которых можно лепить страницы. И вот тут мне бы хотелось, чтобы у самой страницы не было никаких собственных стилей, потому что она должна находится в согласованности с другими страницами и все они должны быть в едином стиле. Поэтому сама страница не должна содержать в себе ничего кроме набора компонент. Это может быть три, пять, сколько угодно компонент, которые представлены простым перечислением. Например, страница "О нас" в самом простом варианте может содержать в себе три компоненты: 1) шапка страницы, 2) описание компании с формой обратной связи и 3) футер. В сложном варианте можно добавить всплывающий виджет горячей линии, панель согласия на использование куков, компоненту сбора аналитики и проч.

Но главным критерием остается чистота компоненты страницы. Поэтому может возникнуть резонный вопрос: а куда девать наполнение страницы? Вот ту самую суть, без хэдера и футера и прочих добавочных виджетов. И на него легко найти ответ, ответив на другой вопрос: а что такое это наполнение страницы? Что это как не экосистема, которая определяет основную цель посещения этой страницы. И вот тут как раз проявляется это важное свойство экосистемы: отражать одну из бизнес-задач приложения.

Правила именования слоев из предметной категории

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

Я ввела правила именования каждого предметного слоя, чтобы уже по названию я могла определить какого уровня компонента. Так, к названиям всех популяций я добавляла _group, экосистемы получили окончание _space, а страницы соответственно _page.

Так же это мне очень помогло с повторяющимися названиями компонент, которые обозначают одну сущность, но находятся на разных уровнях. В случае с абстрактными уровнями (атомами, молекулами и организмами) из-за возможного пересечения названий, приходится быть очень аккуратным при выборе имени. А все мы знаем, что придумать хорошее название функции, компоненте, процессу - это та еще задачка!

Откуда взялись минералы?

Достаточно ли вышеописанных слоев? Кажется, что да, и на этом можно было бы и закончить. Но на практике мне хотелось описать в своем стайлгайде ВСЁ. И оказалось, что за бортом остались статические картинки, утилитарные классы, базовые цвета, шрифты и проч. Какая-то такая непонятная мелочевка, которую нельзя отнести к компонентам, но хочется, чтобы она тоже была в стайлгайде.

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

Так что же такое атомарный дизайн 2.0

Это основанная на практическом применении усовершенствованная методология атомарного дизайна, состоящая из 7 уровней:

1. минералы
2. атомы
3. молекулы
4. организмы
5. популяции (_group)
6. экосистемы (_space)
7. страницы (_page)

где важное место занимает DDD и появляется разбиение на абстрактные компоненты (атомы, молекулы и организмы) и предметные (популяции, экосистемы и страницы), т. е. смысловые, связанные с предметной областью. А также находят отражение вспомогательные элементы дизайна в слое минералов.

В заключение

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