Стандарты

Приоритет готовых решений

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

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

Правила

1. Обязательный поиск перед разработкой

Правило: Перед созданием любого UI-компонента или страницы обязателен поиск готового решения.

Обоснование: Экономия времени, production-ready качество, консистентность.

Чеклист поиска:

- [ ] Проверил shared-модули проекта
- [ ] Проверил Nuxt UI (https://ui.nuxt.com)
- [ ] Проверил Nuxt Charts (https://nuxtcharts.com)
- [ ] Проверил Nuxt Modules (https://nuxt.com/modules)
// ✅ Хорошо
// Задача: Создать data table с сортировкой
// 1. Поиск: Nuxt UI → UTable ✓
// 2. Результат: Использую UTable с встроенной сортировкой
// 3. Кастомизация: Добавляю колонки под свои данные

// ❌ Плохо
// Задача: Создать data table с сортировкой
// 1. Сразу пишу свой компонент с нуля
// 2. Трачу время на сортировку и пагинацию
// 3. Получаю баги и технический долг

2. Иерархия источников

Правило: Соблюдать строгий порядок приоритетов.

ПриоритетИсточникКогда использовать
1Shared-модулиВдруг уже решали эту задачу
2Nuxt UIБазовые UI-элементы
3Nuxt ChartsГрафики, диаграммы
4Nuxt ModulesСпециализированный функционал
5npm-пакетыЕсли нет Nuxt-модуля
6Кастомная разработкаТолько если нет готового

3. Критерии выбора готового решения

Правило: Готовое решение должно соответствовать критериям качества.

КритерийОбязательноЖелательно
Совместимость с Nuxt
Использует Tailwind
TypeScript поддержка
Обновлялся < 6 месяцев
MIT / Apache лицензия
Документация
> 100 stars (для модулей)
Нет критических issues

4. Кастомизация готового

Правило: Кастомизировать через расширение, не через форк.

<!-- ✅ Хорошо: Расширение компонента -->
<template>
  <UCard v-bind="$attrs" class="service-card">
    <template #header>
      <!-- Кастомный header -->
    </template>
    <slot />
  </UCard>
</template>
// ❌ Плохо: Копирование и изменение исходников
// Не делать: скопировать UCard.vue и изменить

5. Обоснование кастомной разработки

Правило: Если готового нет — задокументировать причину.

Формат в MR:

## Кастомный компонент: OrderTimeline

**Причина:** Не найдено готового решения для:
- Интеграции с Ably для realtime updates
- Специфичной бизнес-логики статусов заказа

**Проверено:**
- Nuxt UI: нет Timeline компонента
- Nuxt Modules: нет подходящего
- npm: react-timeline (не Vue)

6. Nuxt Modules — обязательный источник

Правило: Типовой функционал брать из модулей.

ФункционалИскать в Modules / npm
Графикиnuxt-charts, chart
Иконки@nuxt/icon, icons
Изображения@nuxt/image
SEO@nuxt/seo
Авторизация@sidebase/nuxt-auth
Формы@vee-validate/nuxt
Маски вводаmaska
Виртуализацияvue-virtual-scroller

Пример поиска:

https://nuxt.com/modules?q=chart
https://nuxt.com/modules?q=calendar
https://nuxt.com/modules?category=UI

Примеры

Пример: Страница с графиками

Задача: Dashboard с графиками продаж

Чеклист:
- [x] Nuxt UI → UCard для карточек ✓
- [x] Nuxt Charts → Chart для графиков ✓
- [x] Nuxt UI → UTable для таблицы ✓

Результат: 0 кастомных компонентов

Пример: Страница с формой

Задача: Форма создания заказа

Чеклист:
- [x] Nuxt UI → UForm, UFormGroup, UInput ✓
- [x] Zod → валидация ✓
- [x] Nuxt UI → USelect для выбора ✓

Результат: 0 кастомных компонентов

Исключения

Кастомная разработка допускается для:

  1. Доменных компонентов
    • ServiceCard, OrderTimeline
    • Интеграции с realtime сервисами
    • Специфичные формы заявок
  2. Уникальных бизнес-требований
    • Специфичная визуализация данных
    • Кастомные формы заказа
  3. Performance-critical компонентов
    • Canvas-based визуализации

Чек-лист

  • Проверил shared-модули проекта
  • Проверил Nuxt UI
  • Проверил Nuxt Charts
  • Проверил Nuxt Modules
  • Обосновал кастомную разработку (если есть)

Метрики

МетрикаЦель
% готовых решений> 70%
Кастомных компонентов в UI layer< 30

Связанные стандарты