Перейти к основному содержимому

Темизация и дизайн-системы

Цвета, шрифты, отступы и стили компонентов задаются один раз и используются везде, а не выбираются заново в каждом widget. Дизайн-система — это разница между приложением, которому можно сменить оформление за вечер, и приложением, которому нельзя.

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

Что нужно понимать​

  • Где принимается решение о внешнем виде и единственное ли это место
  • Что токен значит по смыслу, а не какой цвет за ним оказался
  • Как тема доходит до widget и что происходит, когда она меняется
  • Какие компоненты принадлежат системе, а какие — фиче
  • Называют ли дизайнер и разработчик одни и те же вещи одинаково

Ключевые темы​

Токены​

  • Семантические имена — surface, onSurface, danger — вместо grey200
  • Цветовые схемы и то, как собрать схему, которая переживёт тёмную тему
  • Шкала типографики и почему фиксированный размер шрифта — это баг с точки зрения доступности
  • Шкалы отступов и радиусов и отказ от произвольных чисел
  • Elevation и тени как токены

Темизация во Flutter​

  • ThemeData, темы компонентов и настройка стиля один раз
  • Расширение темы собственным набором токенов
  • Светлая, тёмная и высококонтрастная темы
  • Чтение темы вместо импорта констант
  • Где заканчиваются Material и Cupertino и начинается ваша система

Дизайн-система на практике​

  • Одна точка входа: фича импортирует UI-кит и больше ничего
  • Компоненты с небольшим, продуманным API
  • Никаких сырых цветов, текстовых стилей и радиусов внутри кода фич
  • Правило держится на линтере, а не на code review
  • Версионирование и изменение компонента, который используется на десятках экранов

Работа с дизайном​

  • Общий словарь между Figma и кодом
  • Что должно входить в handoff
  • Расхождение дизайна и реализации и как его вовремя заметить

Уровни​

УровеньКак это выглядит
JuniorБерёт значения из темы вместо захардкоженных и существующие компоненты вместо новых.
MiddleРасширяет тему токенами, собирает переиспользуемые компоненты, полноценно поддерживает тёмную тему.
SeniorПроектирует систему токенов и API компонентов, закрепляет границу инструментами и может сменить оформление продукта, не трогая фичи.

Практика​

Для начала​

  • Найдите захардкоженные стили Поищите в коде фич Color( и TextStyle( и перенесите каждый случай в тему.

  • Честно поддержите тёмную тему Включите её и почините всё, что не читается, а не только то, что падает.

  • Считайтесь с масштабом текста Выставьте системный размер шрифта на максимум и почините то, что сломалось.

Глубже​

  • Соберите расширение с токенами Добавьте ThemeExtension для токенов, которых нет в Material, и начните им пользоваться.

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

  • Закрепите границу Добавьте правило линтера, которое ломает сборку, когда код фичи создаёт сырой цвет.

Проверьте себя​

  • Сколько мест в вашем приложении решают, как выглядит «primary»?
  • Что ломается при самом большом системном размере шрифта?
  • Смогли бы вы сменить фирменный цвет сегодня и сколько времени это заняло бы?
  • Какие из ваших компонентов относятся к дизайн-системе, а какие просочились в неё?
  • Имена ваших токенов описывают роль или внешний вид?
  • Как вы заметите, что реализация разошлась с дизайном?

Материалы​

  • Material 3 design system — справочник по семантическим ролям цвета и шкалам типографики, полезный, даже если приложение не выглядит как Material. Раздел про цветовую систему объясняет, зачем нужны имена-роли.
  • Use themes to share colors and font styles — официальное руководство по ThemeData и темам компонентов.
  • ThemeExtension — как типобезопасно добавить в тему собственные токены. Механизм, которым стоило бы воспользоваться большинству самодельных классов с токенами.
  • Design Tokens Community Group — складывающийся стандарт описания токенов в виде, понятном и дизайн-инструментам, и коду.
  • Refactoring UI — для разработчиков, которым приходится принимать визуальные решения без дизайнера. Конкретные правила вместо вкусовщины.