Атомный дизайн грязный, вот что я предпочитаю

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

Хорошие детали

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

Плохие части

Есть две вещи, в частности, я вижу проблематично и придумываю, когда объясняю и внедряю систему дизайна …

Это приводит к строгой категоризации

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

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

Вопрос, который, я уверен, был задан в каждой команде, которая применяет атомный дизайн: «Это ли молекула или организм?»
И на самом деле: что делает что-то «маленьким» или «большой» ?
Является ли это количеством элементов или других компонентов, которые он включает?
Тип подчастей, которые он содержит?
Визуальное пространство, которое оно занимает на экране?

Здесь мы находимся в дискуссионных вопросах на концептуальном уровне — но они могут быть отсортированы с ответами и соглашениями, которые команда может согласовать.
Я все время вижу, что это не останавливается на концептуальном уровне:
Команды используют эти категоризации в реализации и помещают компоненты в фактические папки.

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

Это непроходимая абстракция

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

Технические люди могут получить это: Шаблоны представляют собой абстрактную форму, страницы конкретной реализации.
Нетехнические люди борются с этим, если он является частью языка и категоризации.
Даже у меня есть проблемы с установкой шаблонов в документации, так как их сложно представить, а не просто визуально.
Лучший совет, который я могу дать из нашего опыта, — не использовать это различие и путать людей.

Мы закончили разглагольствование?

Серьезно, я не хочу, чтобы это обижало.
Я хотел написать о некоторых моментах, которые я вижу в дискуссиях все время.
Если вы используете Atomic Design и мне нравится, я рад, что он работает для вас и, пожалуйста, придерживайтесь его!

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

Фонд, элементы, модули и прототип

Вот высокоуровневый обзор того, как мне нравится структурировать и реализовывать отдельные части:

• Фонд : Это основной слой дизайнерских жетонов, таких как цвета, типография, расстояния, иконография и т. П.
  В основном, некомпонентные основы, с которыми я сталкиваюсь, когда они определены и классифицируются как атомы.
  Присваивая им явную категорию и называя ее основой, ясно видно, что это влияет на каждую часть системы.

• Элементы : Компоненты «основного строительного блока», о которых все думают, когда говорят об атомах.
  Конкретно они сопоставляются с индивидуальными реализациями отдельных HTML-элементов, таких как заголовки и кнопки.
  Но также и такие элементы, которые не имеют никакого смысла в HTML, когда используются автономные, например, элементы списка.
  В этом случае список будет самой неотделимой формой и, следовательно, элементом.

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

• Прототип : В конечном продукте людям не нужны дизайнерские жетоны, компоненты или шаблоны.
  Им нужны конкретные страницы, которые должны быть собраны из всех этих частей.
  Прототипом является наш раздел в документации по библиотеке шаблонов / проектной документации, где все объединяется.
  Здесь шаблоны, содержащие компоненты, состоят в браке с (образцовыми) данными для формирования страниц, которые все понимают.
  Прототип также является основой для тестирования и проверки идей и функций.

Вот и все!
Извините, это не более причудливо, но мы нашли, что это работает для нас и клиентов и команд, с которыми мы работаем.
Он избегает обсуждений, упомянутых выше.
Это просто и, следовательно, работает без метафоры.

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