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

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

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

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

Первый вариант типографики

Мы начинали с трёх блочных компонентов: Heading, Paragraph, List и одного строчного Text.

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

  1. Приходилось использовать className, где продуктовый разработчик мог указать произвольное значение размеров шрифта, интерлиньяжа и отступов. Таким образом ломался образ продукта.

  2. Не было темизации: для каждого редизайна нужно было переписывать все стили.

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

На тот момент вёрстка выглядела примерно так:

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

По умолчанию вертикальные отступы были выставлены сверху и снизу. Чаще всего приходилось их переопределять с помощью className, потому что не было API для управления отступами у компонентов и не была проработана система отступов для соседних компонентов, например, Heading + Paragraph. А ещё приходилось убирать верхний отступ для первого и нижний для последнего элементов в текстовом блоке.

Второй вариант типографики

Главная идея второй реализации – UI-кит должен быть гибким. Разработчик сам всё определяет на уровни темы, переопределяет на уровне компонента, либо просто указывает через его API.

Звучит хорошо, но для создания сквозного образа продукта эта реализация нам не подходит.

Вот какие проблемы мы увидели:

  1. Темизация не спасала, так как никак не касалась системы отступов — всё было указано вручную. По этой же причине не было гибкости обновления визуальной составляющей.

  2. Продуктовый разработчик мог переопределить всё что угодно. Это рушило общую концепцию образа продукта.

Какие изменения были внесены в UI-кит в связи с этим:

  1. Удалили все типографические компоненты. Оставили только Text, где уже можно было указывать произвольный тэг.

  2. Добавили всё то, что было в CSS: например, margin-top превратился в mt.

  3. Добавили темизацию.

  4. Убрали какие-либо отступы по умолчанию — теперь всё нужно указывать вручную для каждого компонента.

Что изменилось для продукта:

  1. У разработчиков появился универсальный комбайн с которым можно забыть про CSS.

  2. У нас появилось чуть больше головной боли. Коллеги начали приходили с багами, например: «Вот с таким-то сочетанием пропсов у нас ничего не работает, хотя должно».

  3. Для дизайн системы не изменилось ничего — все указанные ранее проблемы остались.

Вёрстка текстового блока могла выглядеть примерно так:

Третий вариант типографики

После второго витка доработок типографика всё ещё не была идеальной. Поэтому в текущей реализации UI-кита мы определили направления работы:

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

  2. Улучшение DX: меньше тайпинга, меньше времени на подбор размера шрифта, интерлиньяжа и отступов.

  3. Сокращение TTM при очередном редизайне.

Получили следующее:

  1. Код стал более лаконичный, много вещей инкапсулировано в самих компонентах.

  2. Код стал ближе ко всеми любимому HTML: мы просто добавили в него необходимые стили.

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

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

Вот результаты, которых мы достигли в этой реализации:

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

  2. Разработчику больше не нужно каких-либо дополнительных пропов. Он может взять компоненты который описан в Figma в текстовых стилях, и всё заработает.

  3. Мы убрали className и style. Теперь разработчика ограничивают только API компонента, которые влияют на его визуальную составляющую и не позволяют отходить от дизайн-спеки и образа продукта.

Вот так примерно выглядит вёрстка с новыми компонентами — теперь она полностью соответствует образу продукта:

Серые практики

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

Сейчас нам не хватает гибкости в работе с отступами, чтобы закрывать редкие кейсы. Поэтому мы добавили возможность указывать их с помощью spaceTop и spaceBottom. И тут есть некоторые моменты:

  • Значения отступов стандартизированы в дизайн-системе. Это не целые числа от 0 до бесконечности, а числа с определённым шагом: 2, 4, 6, 8, 10, 12, 16, 20, 24, … 48, 56, 64. Из-за этого стало тяжелее отойти от дизайн-спецификации.

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

Наши боли и bad practices

Часто разработчики не могут найти подходящего состояния компонента. Это выражается в отличии компонента в UI-ките и того, что есть в макетах в Figma: например, отступы или размер шрифта. Частое решение — сделать локальный костыль и что-то переопределить с помощью каскадности CSS или переопределения CSS-переменных.

Чем это плохо: при очередном обновление UI-кита ваши переопределения либо сломаются, либо зафиксируют старый образ продукта.

Практика показывает, что если разработчик заметил различия между Figma и UI-китом, то лучше поговорить с дизайнером — это поможет избежать 99% костылей.

Предыдущая статья: Чего ждут коллеги разных уровней от тимлида