Есть безошибочный признак макета без компонентов: правка «сделайте кнопки чуть выше» превращается в квест «найди все кнопки». Вы правите одну, вторую, десятую, к сороковой теряете счёт, а на ревью выясняется, что три штуки остались старыми — те, про которые вы забыли. Каждая такая правка — это риск рассогласования, и он копится с каждым экраном. Компоненты придуманы, чтобы этого ада просто не было.
Компонент — это мастер-элемент, а всё, что вы раскладываете по макету, — его экземпляры, наследующие вид. Поменяли мастер-кнопку — и все её экземпляры в проекте обновились сами, включая ту самую, про которую вы бы забыли. Это не просто удобство: это фундамент, на котором вообще держится дизайн-система. Без него «система» — только на словах.
Мастер и экземпляр — кто кому подчиняется
Связь односторонняя и в этом её сила. Мастер диктует облик, экземпляры его повторяют. При этом экземпляр можно локально переопределить — поменять текст кнопки, иконку, подпись — не разрывая связь с мастером: структура и стиль по-прежнему приходят сверху, а конкретное содержимое живёт на месте. Именно поэтому одна мастер-карточка обслуживает и «Товар», и «Услуга», и «Тариф» — каркас общий, начинка разная.
В Rugma эта синхронизация работает вживую: правка мастера доезжает до экземпляров сразу, а локальные переопределения при этом сохраняются. Это ровно то поведение, ради которого компоненты и заводят, — обновлять форму, не затирая содержание.
Варианты: одна кнопка вместо десяти
Дальше начинается настоящая экономия. У любого компонента есть измерения, вдоль которых он меняется: кнопка бывает основной и второстепенной, обычной и наведённой, маленькой, средней и большой. Заводить под каждое сочетание отдельный элемент — путь к библиотеке из полусотни почти одинаковых кнопок, в которой невозможно навигировать. Вместо этого их собирают в группу вариантов: type = primary / ghost, state = default / hover / disabled, size = sm / md / lg. На макете вы кладёте один компонент и просто переключаете свойства — как тумблеры.
Выгода двойная. Во-первых, порядок: вся кнопка — одна сущность в библиотеке, а не россыпь. Во-вторых, честность: варианты заставляют вас продумать все состояния заранее, а не вспоминать про disabled в последний день перед сдачей. Хорошо собранная группа вариантов — это ещё и чек-лист того, что вы ничего не забыли.
Что выносить в компоненты, а что нет
Правило большого пальца простое: если элемент встречается трижды — ему пора стать компонентом. Кнопки, поля ввода, карточки, аватары, иконки, теги, ячейки таблиц, элементы навигации — всё это кандидаты по определению. А вот уникальную иллюстрацию на лендинге или единственный промо-баннер заворачивать в компонент незачем — вы потратите время на абстракцию, которой не воспользуетесь.
Есть и обратная крайность — слишком ранняя компонентизация. Пока вы ещё ищете форму, жёсткий мастер мешает экспериментировать. Разумный порядок такой: сначала набросали пару экранов свободно, увидели, что повторяется, — и только тогда вынесли повторяющееся в компоненты. Система должна расти из практики, а не предшествовать ей.
Попробуйте прямо сейчас. Откройте редактор, соберите кнопку в горизонтальном авто-лейауте, превратите её в компонент и заведите вариант ghost — с прозрачным фоном и обводкой. Разложите пять экземпляров по макету, часть переключите в ghost. Теперь измените в мастере скругление — и посмотрите, как перекруглятся все пятеро разом. Вот эта секунда и окупает всё время, потраченное на сборку.
Библиотека, в которой не потеряешься
Компоненты решают проблему повторов, но создают новую — их самих становится много, и без порядка библиотека превращается в свалку, где проще нарисовать заново, чем найти нужное. Спасает дисциплина именования. Называйте компоненты по назначению и группируйте по семействам через понятный разделитель: Кнопка/Основная, Поле/Текст, Карточка/Товар. Тогда родственные элементы собираются рядом сами собой, а поиск по имени находит то, что нужно, с первой попытки.
Второе правило — один компонент на одну роль. Если вы ловите себя на том, что заводите «почти такую же карточку, только чуть иначе», почти всегда это не новый компонент, а новый вариант существующего. Сопротивляйтесь соблазну плодить близнецов: чем меньше в библиотеке сущностей, тем легче держать её согласованной. Хорошая библиотека узнаётся не по количеству компонентов, а по тому, как быстро в ней находится нужный.
И заранее подумайте о состояниях-пустышках: пустой список, загрузка, ошибка. Их удобно оформить отдельными компонентами и переиспользовать по всему продукту — тогда «пусто» и «что-то пошло не так» будут выглядеть одинаково аккуратно везде, а не рисоваться наспех в последний момент.
Компоненты и токены — лучшие друзья
Компоненты раскрывают полную силу в паре с дизайн-токенами. Если кнопка-мастер ссылается на семантический цвет, а не на сырой #hex, то при ребрендинге меняется один токен — и перекрашиваются все экземпляры всех вариантов во всём проекте. Именно так собрана дизайн-система «Грань» — смена одного токена перекрашивает всю витрину. Токены отвечают за «чем», компоненты — за «что», а вместе они дают систему, которая переживает и смену бренда, и рост продукта. Внутреннее устройство компонента при этом почти всегда — авто-лейаут, чтобы варианты с разной длиной текста не разъезжались.
Нужна готовая библиотека под продукт, а не месяц на её сборку? Закажите дизайн-систему под ключ — соберём компоненты с вариантами, темами и токенами в Rugma и передадим проект вместе с готовым кодом.