Верстка сучасних інтерфейсів: досвід використання Shadcn/UI

Верстка сучасних інтерфейсів: досвід використання Shadcn/UI

Сталкивалися з тим, що готовий UI-kit не вписується в дизайн, а кастомізація перетворюється на перевизначення стилів через !important? Material UI та Chakra UI додають тони невикористовуваного коду, а SSR-підтримка вимагає окремого налаштування. Shadcn/UI вирішує цю проблему інакше: він не бібліотека, а колекція компонентів, які можна скопіювати, на основі Radix UI та Tailwind CSS. Весь код потрапляє у ваш репозиторій — ви контролюєте кожен піксель.

Наша команда впроваджує Shadcn/UI з моменту його виходу. За цей час реалізували понад 50 рішень: від адмін-панелей до лендінгів з високою конверсією. Один з клієнтів, перейшовши з Material UI, заощадив близько 150 000 грн на переписуванні коду — Shadcn/UI виявився втричі легшим за розміром бандла і не вимагав додаткових налаштувань для SSR. В іншому проєкті вдалося скоротити час розробки на 2 тижні, що заощадило 80 000 грн на трудозатратах.

Чому Shadcn/UI швидший за інші UI-бібліотеки?

Головна проблема великих UI-фреймворків — надлишковість. Ви тягнете 100+ компонентів, а використовуєте 5-10. Shadcn/UI працює інакше: ви встановлюєте лише те, що потрібно. Це знижує розмір bundle на 30–40% і покращує Core Web Vitals — LCP падає на 15-20% порівняно з Material UI. Доступність вбудована в кожен компонент завдяки Radix UI, тому вам не потрібно турбуватися про ARIA-атрибути.

Друга проблема — кастомізація. У Shadcn/UI немає оверрайдів: ви правите вихідний код компонента. Хочете зробити кнопку з градієнтом? Додайте рядок у variant-об'єкт. Потрібна нестандартна типографіка? Змініть CSS-змінні. При цьому базова доступність (ARIA-атрибути, фокус, клавіатурна навігація) вже вшита.

Третя — темна тема. У Shadcn/UI вона реалізована через CSS-змінні: перемикання класу dark на кореневому елементі автоматично змінює кольори. Жодних додаткових провайдерів чи стилів.

Як кастомізувати компоненти без втрати оновлень?

Розглянемо типовий кейс: лендінг для SaaS-продукту на Next.js 14 з TypeScript і Tailwind. Ми починаємо з ініціалізації Shadcn/UI:

npx shadcn@latest init

CLI запитує стиль (default/new-york), базовий колір та аліаси. Конфігурація записується в components.json:

{
  "$schema": "https://ui.shadcn.com/schema.json",
  "style": "new-york",
  "rsc": true,
  "tsx": true,
  "tailwind": {
    "config": "tailwind.config.ts",
    "css": "src/styles/globals.css",
    "baseColor": "slate",
    "cssVariables": true
  },
  "aliases": {
    "components": "@/components",
    "utils": "@/lib/utils"
  }
}

Далі додаємо потрібні компоненти: button, card, dialog, input, form. Кожен файл з'являється в components/ui/. Наприклад, діалог з формою:

import { Dialog, DialogContent, DialogHeader, DialogTitle, DialogTrigger } from '@/components/ui/dialog';
import { Button } from '@/components/ui/button';

const ContactDialog = () => (
  <Dialog>
    <DialogTrigger asChild>
      <Button>Зв'язатися</Button>
    </DialogTrigger>
    <DialogContent>
      <DialogHeader>
        <DialogTitle>Залиште заявку</DialogTitle>
      </DialogHeader>
      <form className="flex flex-col gap-4">
        <input name="name" placeholder="Ваше ім'я" />
        <input name="email" type="email" placeholder="Email" />
        <Button type="submit">Відправити</Button>
      </form>
    </DialogContent>
  </Dialog>
);

Кастомізація не вимагає перевизначень: додати новий варіант кнопки — правимо button.tsx:

const buttonVariants = cva(
  'inline-flex items-center justify-center ...',
  {
    variants: {
      variant: {
        default: '...',
        gradient: 'bg-gradient-to-r from-blue-600 to-purple-600 text-white hover:opacity-90',
      },
    },
  }
);

Процес роботи над проєктом

1. Аналітика (1-2 дні): вивчаємо макети, виділяємо повторювані UI-блоки, визначаємо необхідні компоненти.
2. Проєктування (1 день): налаштовуємо тему (кольори, типографіку, анімації), створюємо базовий layout.
3. Реалізація (2-4 дні): інтегруємо компоненти, адаптуємо під дизайн, перевіряємо стан завантаження/помилки/порожні дані.
4. Тестування (1 день): перевіряємо доступність (скрінрідери, клавіатура), адаптивність, продуктивність (Lighthouse 90+).
5. Деплой (0.5 дня): налаштовуємо збірку, кешування, підключаємо аналітику.

Що входить в роботу

• Вихідний код усіх компонентів з TypeScript та JSDoc.
• Файл globals.css з коректними CSS-змінними під ваш бренд.
• Адаптивна верстка (mobile-first) з breakpoints.
• Темна тема (якщо потрібно).
• Коротка документація: як додати новий компонент, як оновити через npx shadcn diff.
• Навчання вашої команди (1 година дзвінок) — розповімо про best practices.
• Підтримка протягом 2 тижнів після здачі.

Терміни та вартість

Вартість розраховується індивідуально — залежить від кількості компонентів та складності кастомізації. Оцінка безкоштовна і займає не більше 24 годин. Замовте верстку на Shadcn/UI — ми гарантуємо код без помилок hydration, 100% відповідність макету та проходження Core Web Vitals. Отримайте консультацію за 24 години — зв'яжіться з нами, щоб обговорити ваш проєкт.

Фронтенд-розробка React: від аудиту до production

Бандл виріс до 3.1 MB gzip — це реальна цифра з проєкту, який прийшов до нас на аудит. Причина: moment.js (72 KB) тягнув локалі для всіх 160 мов, lodash імпортувався цілком замість tree-shake, три компонентні бібліотеки підключено одночасно. TTFB відмінний, але TTI (Time to Interactive) на мобільному — 14 секунд. Користувачі йшли, конверсія впала на 40%. Ми переписали фронтенд: прибрали дублювання бібліотек, впровадили динамічні імпорти та SSR. Результат — бандл зменшився до 850 KB gzip, TTI — 2.1 секунди, LCP — 1.8 с.

Frontend — це не «намалювати красиво». Це продуктивність, типізація, стратегія рендерингу, bundle management і підтримуваність на роки.

Чому Next.js — стандартний вибір для SEO?

React — наш основний UI-фреймворк для складних інтерфейсів. Next.js — стандартний вибір для проєктів з SEO-вимогами або SSR. App Router (з версії 13) приніс React Server Components, streaming та fetch із built-in кешуванням. Це реальні переваги: сторінка каталогу з тисячами товарів рендериться на сервері без відправки логіки фільтрації на клієнт, JS-бандл менший на 30%.

Але App Router — інший спосіб мислення. "use client" потрібно ставити свідомо. Реальна помилка: розробник позначає весь layout як "use client" через один стан навігації — і втрачає всі переваги RSC. Правило: тримати Server Components якомога вище в дереві, "use client" — тільки для інтерактивних листових компонентів. ISR (Incremental Static Regeneration) — потужний інструмент для контентних сайтів. На каталозі з 50 000 сторінок з ISR та CDN — TTFB < 50 ms для будь-якої сторінки.

Як TypeScript запобігає багам у продакшені?

TypeScript обов'язковий на будь-якому проєкті, який планується підтримувати довше 3 місяців або в команді більше одного розробника. Аргумент «пишемо швидко без типів» працює лише перші 2 тижні. Після — баги, пов'язані з невизначеними значеннями, виникають щотижня.

Конкретна користь: рефакторинг API-відповіді — змінив тип в одному місці, TypeScript показує всі місця, де потрібно адаптувати код. Без типів — баг у продакшені через тиждень. strict: true в tsconfig.json — обов'язково. noImplicitAny, strictNullChecks, strictFunctionTypes. Біль від Type 'undefined' is not assignable у розробці коштує менше, ніж Cannot read properties of undefined у продакшені. tRPC — end-to-end типізація від бекенду до фронтенду без окремої схеми — змінюючи тип процедури, ви одразу бачите місця на фронтенді, що потребують правки.

Vue 3 + Nuxt 3 — альтернативний стек для SSR

Vue 3 з Composition API — інший стиль розробки, ближчий до React Hooks. <script setup> та composables роблять код більш перевикористовуваним. Nuxt 3 — фреймворк для Vue з SSR/SSG, аналогічний Next.js. useAsyncData та useFetch — вбудовані composables з дедуплікацією запитів та hydration. Auto-imports зручні, але можуть заплутувати при debug. Nuxt Content — модуль для Markdown/MDX-файлів, ідеальний для документації.

Hydration mismatch — специфічний біль SSR на Vue та React. Рішення: <ClientOnly> компонент для браузерного контенту, suppressHydrationWarning для dynamic timestamps.

Продуктивність: метрики та інструменти

Bundle analysis — стартова точка. @next/bundle-analyzer або rollup-plugin-visualizer — запускаємо перед кожним мажорним деплоєм. Мета: жодна сторінка не повинна вимагати > 200 KB JS gzip для first paint.

Динамічні імпорти для важких компонентів:

const RichEditor = dynamic(() => import('@/components/RichEditor'), {
  ssr: false,
  loading: () => <EditorSkeleton />,
});

Редактор (Tiptap, Quill, CodeMirror) — типові кандидати на dynamic import. Без цього вони потрапляють в основний бандл. React DevTools Profiler — для пошуку зайвих ре-рендерів. React.memo, useMemo, useCallback — точкові інструменти. Передчасна мемоізація всього підряд додає overhead без користі. Профілюйте спочатку, оптимізуйте потім.

Віртуалізація довгих списків: @tanstack/virtual або react-window рендерять лише видимі елементи. Таблиця з 50 000 рядків: з віртуалізацією — 60fps, без — браузер зависає при скролі.

State management: без овериніжирингу

Для більшості додатків достатньо:

• React Query / TanStack Query — для серверного стану (дані з API, кешування, інвалідація)
• Zustand — для глобального клієнтського стану (легковаговий, без boilerplate Redux)
• React Hook Form — для форм

Redux Toolkit виправданий для дуже складного глобального стану з великою кількістю взаємодій. Для більшості задач — це overkill. Recoil, Jotai — атомарні підходи для незалежних шматків стану.

CSS та дизайн-система

Tailwind CSS останньої версії — наш стандартний вибір для нових проєктів. Utility-first, відмінна інтеграція з компонентними бібліотеками (Radix UI, Headless UI), PostCSS pipeline. CSS Modules — альтернатива, коли потрібна більш явна ізоляція стилів. Radix UI + Tailwind (Shadcn/ui паттерн) — headless компоненти з повним контролем над стилями. Немає dependency lock-in: компоненти копіюються в проєкт і повністю кастомізуються. Storybook — для документування компонентної бібліотеки. React DevTools Profiler — офіційний інструмент від команди React.

Тестування

E2E тести через Playwright — для checkout, авторизації, критичних форм. Не для всього підряд: підтримка великої e2e-сюїти дорога, тому обираємо 3-5 ключових сценаріїв.

Орієнтири за термінами та складом робіт

Вартість розраховується після декомпозиції на компоненти, екрани та інтеграції з API. Ми використовуємо N+1 оцінку: додаємо 20% на ризики.

Що входить в роботу: вихідний код в Git, документація по архітектурі та компонентах, доступ до CI/CD, навчання вашої команди (2-3 зустрічі), гарантія 3 місяці на виявлені баги. Додатково — покриття юніт-тестами ключових модулів.

У нас 5 років досвіду у фронтенд-розробці, понад 50 виконаних проєктів, команда з 10 інженерів, що володіють React, Vue, Angular. Працюємо з технологіями, описаними в документації React та TypeScript. Додаткові відомості можна знайти в Wikipedia: React та Wikipedia: TypeScript.

Який стек обрати для фронтенд-розробки React?

Ми порівнюємо інструменти за реальними метриками. Next.js швидший за Nuxt у збірці SSR на 20–30% при однаковому розмірі сторінки. TypeScript знижує кількість production-багів на 60–70% у порівнянні з JavaScript. Економія на підтримці такого проєкту — значна за рахунок скорочення часу на налагодження. Якщо вам потрібен легкий SPA з мінімальною вартістю — достатньо React + Vite. Для контентного сайту з SEO — Next.js з ISR дає TTFB нижче 50 мс навіть при 50 000 сторінок.

Отримайте консультацію по вашому проєкту: оцінимо поточний код і запропонуємо план оптимізації. Замовте аудит — знайдемо вузькі місця та покажемо, як скоротити бюджет без втрати якості.