Теги в названии компонентов

Источник: ds-docs/reference/guidelines/naming-tags.md

Система тегов в названиях компонентов: что обозначает каждый тег, как именовать компоненты и можно ли их переиспользовать.

«Тег — это пометка в названии компонента, которая сообщает его роль и принадлежность.» Теги делятся на два независимых семейства:

• Теги-префиксы (в начале названия) — что это за компонент по роли. Общие для всей ДС.
• Теги-суффиксы (в конце названия) — кому принадлежит компонент и можно ли его переиспользовать. Про продукт и продуктовую команду.

«Оси независимы: у компонента может быть только префикс, только суффикс, оба сразу или ни одного.» Связано: README, ds-internal/AUDIT.md, Версии компонента, component-authoring-rules.

Сводная таблица

⚠️ В самой сводной таблице тег записан как ❌ Depricated (опечатка), а в тексте раздела — ❌ Deprecated. Каноничным считаем ❌ Deprecated (Q-001).

---

Семейство 1. Теги-префиксы — роль компонента

«Стоят перед названием. Описывают, какую роль компонент играет в системе и для кого он сделан. Общие для всей дизайн-системы.»

Базовый компонент (без префикса)

• Что это. «Основной, „боевой“ компонент дизайн-системы, заточенный под сборку макетов дизайнерами.»
• Особенность. «Внутри уже включены и подставлены через swap-свойства наиболее часто используемые вложенные компоненты. Это удобно дизайнеру, но скрывает реальную структуру и полный набор свойств — поэтому для разработчиков существует отдельный Dev Example.»

Dev Example {название компонента}

• Назначение. «Демонстрационный компонент, показывающий разработчику, как базовый компонент должен выглядеть на самом деле и какими свойствами обладать.»
• Зачем нужен. Базовый компонент заточен под дизайнеров — swap-подстановки мешают разработчику увидеть реальную структуру. «Dev Example раскрывает „эталонный“ вид и поведение в чистом виде.»
• Аудитория. Разработчики — как референс при реализации.
• Важно. «Не используется в боевых макетах — это справочный артефакт.»

DP {базовый компонент} {контекст / история} — Design Pattern

• Назначение. «Готовая контентно-визуальная сборка на основе базового компонента — „упакованный паттерн“, который нужен сразу в нескольких местах макета.»
• Зачем нужен.
  • «Переиспользование — один и тот же наполненный паттерн вставляется в разных местах.»
  • «Единая точка правки — правишь внутренний контент в одном месте → обновляется везде.»
• Как создаётся.
  1. «Берём базовый компонент (например, Layer).»
  2. «Наполняем его контентную область нужным содержимым.»
  3. «Оборачиваем наполненный экземпляр в новый компонент.»
  4. «Именуем по правилу DP.»
• Пример. «Layer — заголовок + контентная область (слот), в которую можно положить любые компоненты или нужный контент. Используется в большинстве историй в макетах.»
• Аудитория. Дизайнеры — для сборки макетов.

❌ Deprecated {название компонента} — статусный префикс

Добавлено командой ДС поверх исходной справки (2026-07-15).

• Что это. «Префикс из иконки-крестика (❌) и слова „Deprecated“ в начале названия.»
• Назначение. «Помечает компонент, который больше не поддерживается на будущее. Его ещё можно встретить и использовать в уже существующих макетах, но в новых макетах и новых флоу использовать не рекомендуется — вместо него берётся актуальная (Stable) версия компонента.»
• Особенность. «Это статусная метка, а не роль. Она может стоять у чего угодно, что выводится из обращения: у базового компонента, у DP, у продуктовых форков с суффиксами.»
• Практика. «Увидел ❌ Deprecated в своём макете — при ближайшей пересборке замени на актуальный компонент; в новый флоу не тащи.»

«В файлах встречались разные написания пометки об устаревании (❌ Description, ❌ Deprecated, ❌ <Name> (используйте <Name>)). Каноничным считаем «❌ Deprecated {название}»; остальные приводим к нему.»

Версии компонента (Stable / Deprecated и пр.) — Версии компонента.

Префиксы уровня — Page / Template (атомарный дизайн)

«Отдельная группа префиксов описывает уровень компонента по атомарному дизайну — какого рода экран перед тобой и насколько он изменяем. Оба относятся к уровню „страница“, разница — в степени открытости для наполнения.»

Page {название} — страница

«Компонент-экран с фиксированным, неизменным поведением. Всё, что помечено Page, — это конкретный вид экрана, который ведёт себя строго одним образом; наполнять или переопределять его не предполагается, используется как есть.»

Template {название} — шаблон

«Компонент-экран с поведением шаблона. Такой вид страницы можно переиспользовать и заполнять данными через открытые пропсы, которые дают возможность редактирования содержимого. По сути Template — это Page, у которого намеренно открыты точки наполнения (слоты/пропсы) под конкретный контент.»

Разница коротко: «Page — смотри и используй как есть (поведение зашито); Template — бери и наполняй (поведение зашито, контент открыт через пропсы).»

---

Семейство 2. Теги-суффиксы — продуктовая принадлежность

«Стоят в конце названия. Обозначают, кому принадлежит компонент и где он живёт (в какой библиотеке, в дизайне и в коде). Главное, что кодирует суффикс, — границу переиспользования.»

Уровни принадлежности:

1. «Общая дизайн-система (без суффикса) — переиспользуемые компоненты, лежат в общей библиотеке и в дизайне, и в коде.»
2. «Продукт (двухбуквенный суффикс) — компонент принадлежит конкретному продукту; у продукта могут быть свои библиотечные компоненты.»
3. «Продуктовая команда (трёхсоставной суффикс) — компонент принадлежит конкретной команде, переиспользованию не подлежит.»

Двухбуквенный суффикс — продукт

• Назначение. «Обозначает принадлежность компонента конкретному продукту.»
• Пример. «AF = Astra Fintech → компонент относится к финтех-направлению продукта.»
• Особенность. «В рамках продукта существуют свои библиотечные компоненты (подгруппы продуктовых компонентов). Это всё ещё переиспользуемые компоненты, но в границах продукта.»
• Правило именования. {Название компонента} AF (суффикс в конце).
• Аудитория. Дизайнеры и разработчики продукта.

Трёхсоставной суффикс — продуктовая команда

• Назначение. «Обозначает принадлежность компонента конкретной продуктовой команде.»
• Что это. «У продуктовых команд есть собственные компоненты, которых нет в общей дизайн-системе. Они построены на наших принципах и токенах, но являются собственными компонентами команды.»
• Ключевое правило — не переиспользовать. «Такой компонент используется только внутри одной команды. В коде он не лежит в общей библиотеке — как и в дизайне. Трёхсоставной суффикс служит явным маркером: „это командный компонент, переиспользовать нельзя“.»
• Правило именования. {Название компонента} {ХХХ}, где ХХХ — трёхсоставной тег команды.
• Аудитория. Только команда-владелец.

---

Справочник кодов

Глобальные коды продуктов (2 буквы)

⚠️ SB выдан дважды — «Свой Бизнес» и «Сайт банка» (Q-002).

Локальные коды продуктовых команд (3 буквы)

Пометки ⚠️ разобраны в «Открытых вопросах» ниже.

Запросить новый код

---

Связь с аудитом

• То, что базовые компоненты «прячут структуру» через swap — намеренно; ответ на это Dev Example. Не считать это находкой.
• Часть кажущихся «дублей» легальна: компоненты с суффиксами AF или командными — намеренные продуктовые/командные форки. При разборе дублей сверяться с суффиксом.
• Компоненты с префиксами Page / Template — уровень «страница», а не атом/молекула; в инвентаре их не сравнивать с компонентами ДС.
• Опечатки, кириллица в латинских названиях и битые версии к системе тегов отношения не имеют — остаются находками (см. ds-internal/AUDIT.md).

Открытые вопросы

Источник

• buildin.ai, «Гайды → Компонентные библиотеки → Теги компонентов» b9f596cc-5773-4611-a559-cf082abccae2 — префиксы, суффиксы, сводная таблица.
• Подстраница «Продуктовые теги» 686c9762-a368-41e2-b267-1c093aeac540 — локальные коды команд.
• Страница «Семантические коды» cdec6649-6f41-4c71-b21f-41dd6440c275 («Привет! Это Астра → Ресурсы и материалы») — глобальные коды продуктов, локальные коды, контакты для запроса нового кода.
• Прочитано 2026-07-30; таблицы сняты из блочной модели документа (в вёрстке они виртуализированы и в текст страницы не попадают).