Использование принципов атомарного дизайна с библиотеками компонентов для современной веб-разработки

Атомарный дизайн помогает разработчикам думать о пользовательских интерфейсах как о наборе компонентов и позволяет им разбивать целые интерфейсы на фундаментальные строительные блоки и создавать более согласованные пользовательские интерфейсы.

Итак, в этой статье я помогу вам понять концепции атомарного дизайна и адаптировать их к современной разработке.

Краткое введение в атомарный дизайн

В основном атомарный дизайн используется для систем проектирования. Он привносит 5 простых идей из химии в веб-разработку: атомы, молекулы, организмы, шаблоны и страницы. Преимущество здесь в том, что терминология не требует пояснений.

1. Атомы:

Атомы - это основной строительный блок всего. Таким образом, в веб-разработке такие первичные элементы, как теги HTML, ярлыки, кнопки, можно рассматривать как атомы.

Здесь важно проанализировать контекст своего продукта и придумать атомы. Например, вы можете определить Atom for Aviator со свойством variant, поддерживающим изображения квадрат и круг.

2. Молекулы:

Они более осязаемы и могут быть идентифицированы как группа атомов, связанных вместе. Таким образом, молекулы служат основой системы дизайна. А сочетание поля поиска и кнопки можно рассматривать как Молекулу.

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

3. Организмы:

Организм - это комбинация молекул и атомов, образующая небольшой сложный, особый компонент. Например, заголовок или нижний колонтитул с кнопками и логотипом можно рассматривать как организм.

Отличие от Molecule состоит в том, что она также будет управлять состоянием и станет полностью функциональной как единое целое.

4. Шаблоны:

Шаблоны, как следует из названия, представляют собой многоразовые коллекции организмов, молекул и атомов, вместе взятых. Поэтому они более конкретны.

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

5. Страницы:

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

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

Создание компонентов с нуля?

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

Кроме того, эти библиотеки пользовательского интерфейса обеспечивают поддержку тем, которая присутствует во всей системе дизайна.

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

Эволюция атомарного дизайна в современном контексте

Начнем с вопроса, который задают довольно часто. Являются ли следующие элементы атомами? Пример взят из пользовательского интерфейса материала.

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

Итак, что мы можем сделать, чтобы сделать его более подходящим для вашей дизайн-системы?

  • Мы можем начать с определения вариантов, которые мы должны разрешить в нашей системе дизайна для атомов (например, Button). Возможно, мы выберем два варианта «Заливка» и «Обводка» и два размера. Это все.
  • И также важно, чтобы был только один атом с именем Button с вариантами и свойствами (например, размером). В противном случае, если у нас есть XButton, YButton, RoundButton и будет слишком много атомов, разработчикам придется потратить больше времени на выяснение их имен. и ищу их. Таким образом, наличие одного Atom for Button поможет разработчикам использовать его и заглядывать в свойства, чтобы понять его различные конфигурации.

Больше в Theming

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

Сложность состоит в том, чтобы определить их на атомах, молекулах, организмах или на другом уровне? Ответ прост, если мы определяем тематику вне этих компонентов. Современные библиотеки пользовательского интерфейса, такие как MaterialUI, также поддерживают его.

<ThemeProvider theme={theme}>
  <CustomCheckbox />
</ThemeProvider>

Мы можем настроить свойства темы на более высоком уровне.

import { createTheme } from '@material-ui/core/styles';
import purple from '@material-ui/core/colors/purple';
import green from '@material-ui/core/colors/green';

const theme = createTheme({
  palette: {
    primary: {
      main: purple[500],
    },
    secondary: {
      main: green[500],
    },
  },
});

Поскольку каждый компонент наследует тему, если мы хотим настроить его уникально для нашего приложения (например, Button), мы можем переопределить свойства, исходящие из темы, на уровне Atom.

А как насчет наименования компонентов?

Возникает следующий вопрос, должны ли мы переименовывать компоненты, доступные в библиотеках пользовательского интерфейса, в соответствии с соглашением об именах Atoms, Molecules & и т. Д.

Например, вы можете определить свой ButtonAtom с ограниченными свойствами, обернув компонент Button, который поставляется с MaterialUI, следующим образом;

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

Все идет нормально? Что будет дальше после создания вашей дизайн-системы? Как мы должны делиться этим между проектами?

Совместное использование дизайн-системы

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

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

Заключение

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

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

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

Спасибо за чтение !!!

Подробнее