Урок 16. Домашнее задание: обоснование выбора
⚡ Кратко
Подготовить обоснованное решение: подходит ли shadcn/ui вашему проекту. Документ на одну страницу с аргументами, рисками и планом.
Задание
Возьмите реальный или воображаемый проект и напишите короткий документ (полстраницы-страница) по структуре:
- Контекст: что за проект, кто в команде, есть ли дизайнер и макеты.
- Требования к интерфейсу: насколько дизайн уникален, нужна ли тёмная тема, есть ли требования по доступности.
- Решение: shadcn/ui, готовая библиотека или свои компоненты.
- Аргументы: три «за» и минимум один честный «против».
- Риски и как их снижаем: кто владеет
components/ui, как обновляем, что делаем с расхождениями.
Подготовка окружения
Для этого задания код не нужен, но полезно посмотреть, как выглядит реестр вживую:
npx shadcn@latest search # какие элементы доступны
npx shadcn@latest view button # исходник конкретного компонентаПошаговое решение
Шаг 1. Честно оцените ресурс
Главный вопрос — не «нравится ли подход», а «кто будет вести компоненты через полгода». Если ответа нет, это сильный аргумент в пользу готовой библиотеки.
Шаг 2. Оцените уникальность дизайна
Чем ближе макет к «стандартному», тем выгоднее библиотека. Чем больше в макете собственных решений, тем быстрее вы упрётесь в её API.
Шаг 3. Проверьте требования по доступности
Если проект обязан соответствовать нормам доступности, слой примитивов — сильный аргумент: он закрывает большую часть требований к поведению.
Шаг 4. Опишите процесс
Кто ревьюит изменения в components/ui, как часто сверяемся
с реестром (--diff), где фиксируем отличия от «ванильной»
версии.
Как проверить
- В документе есть хотя бы один аргумент против выбранного решения.
- Указан ответственный за компоненты.
- Описан процесс обновления, а не только первичная установка.
- Решение опирается на контекст проекта, а не на моду.