Розробка фронтенду на TypeScript: строга типізація в дії

Розробка фронтенду сайту на TypeScript

Рефакторинг великого JavaScript-проєкту — це лотерея. Одна помилка в імені методу, і баг іде в продакшен. TypeScript вирішує цю проблему на етапі компіляції. Anders Hejlsberg, творець TypeScript, казав: "TypeScript — це JavaScript, який масштабується." Ми інтегруємо TypeScript у фронтенд з нуля або мігруємо існуючий проєкт. Налаштовуємо строгий tsconfig, автогенерацію типів з OpenAPI-схем, і слідкуємо, щоб код залишався чистим без any.

Наша команда має 6+ років досвіду роботи з TypeScript, реалізувала 40+ проєктів з повною типізацією. Ми гарантуємо, що в продакшен-коді не буде жодного any (винятки документуються). За нашими даними, строга типізація скорочує час code review на 30% і запобігає до 90% помилок типів. Вартість підтримки таких проєктів знижується на 40%.

Які проблеми вирішує TypeScript?

Основний біль — невідповідність типів між фронтендом і бекендом. Коли API повертає поле, якого немає в очікуваному інтерфейсі, JavaScript мовчки продовжує роботу, доки не виникне помилка в рендері. TypeScript ловить це на етапі збірки. Друга проблема — рефакторинг: зміна структури сутності може зламати десятки компонентів, і лише компілятор підсвітить усі місця. Третя — самодокументованість: типи слугують контрактом, зрозумілим кожному розробнику.

Чому TypeScript?

TypeScript — це не просто "JavaScript з типами". Це інструмент, який робить рефакторинг передбачуваним, документує контракти між модулями і ловить цілий клас помилок на етапі компіляції. Для проєктів з командою від двох осіб або терміном життя більше року TypeScript — не опція, а базова вимога. Строга типізація запобігає до 40% помилок, які в JavaScript виявляються лише в рантаймі. За даними досліджень, кожна помилка, виявлена на етапі компіляції, економить у середньому $500. Порівняно з чистим JavaScript, TypeScript у 2 рази швидше виявляє логічні невідповідності, що прискорює цикл розробки. Автогенерація типів прискорює інтеграцію з API в 1.5 рази.

Як TypeScript допомагає уникнути багів у рантаймі?

Типізація API-відповідей — один із перших кроків на будь-якому проєкті. Ручне написання стомлює і застаріває разом з бекендом. Правильний підхід — автогенерація типів з OpenAPI-специфікації. Це дає точні типи для всіх endpoint'ів і типобезпечний клієнт без as і any.

npx openapi-typescript https://api.example.com/openapi.json -o src/types/api.ts

import createClient from 'openapi-fetch';
import type { paths } from '@/types/api';

const client = createClient<paths>({ baseUrl: 'https://api.example.com' });

// TypeScript знає тип параметрів і відповіді
const { data, error } = await client.GET('/products/{id}', {
  params: { path: { id: '42' } }
});

if (data) {
  console.log(data.name); // string — без as, без any
}

Конфігурація для строгого TypeScript

// tsconfig.json
{
  "compilerOptions": {
    "target": "ES2022",
    "lib": ["ES2022", "DOM", "DOM.Iterable"],
    "module": "ESNext",
    "moduleResolution": "bundler",
    "strict": true,
    "noUncheckedIndexedAccess": true,
    "noImplicitOverride": true,
    "exactOptionalPropertyTypes": true,
    "paths": {
      "@/*": ["./src/*"]
    }
  }
}

strict: true включає 8 прапорців одночасно. noUncheckedIndexedAccess додає undefined до типу при доступі до масиву за індексом — половина runtime-помилок зникає сама собою. Рекомендуємо також увімкнути noFallthroughCasesInSwitch і strictNullChecks (вже в strict). Для великих команд — noUnusedLocals і noUnusedParameters.

Discriminated union для станів завантаження

type AsyncState<T> =
  | { status: 'idle' }
  | { status: 'loading' }
  | { status: 'success'; data: T }
  | { status: 'error'; message: string };

function renderState<T>(state: AsyncState<T>): string {
  switch (state.status) {
    case 'idle': return 'Натисніть для завантаження';
    case 'loading': return 'Завантаження...';
    case 'success': return `Завантажено: ${JSON.stringify(state.data)}`;
    case 'error': return `Помилка: ${state.message}`;
  }
}

Компілятор перевіряє exhaustiveness — якщо додати новий статус, усі switch-вирази без нього стануть помилкою.

Branded types для запобігання переплутуванню ID

type UserId = string & { readonly __brand: 'UserId' };
type ProductId = string & { readonly __brand: 'ProductId' };

function toUserId(id: string): UserId { return id as UserId; }

function getUser(id: UserId): Promise<User> { ... }

const productId: ProductId = toProductId('abc');
getUser(productId); // Помилка компіляції: ProductId не сумісний з UserId

Налаштування лінтінгу

Використовуємо eslint c @typescript-eslint/strict-type-checked. Правило no-floating-promises ловить незавершені promise-ланцюжки, які інакше мовчки проковтуються.

Інтеграція з фреймворками

TypeScript працює з будь-яким фронтенд-стеком:

Порівняння конфігурацій TypeScript

Процес роботи

1. Аудит поточного коду — визначаємо слабкі місця та відсутність типів.
2. Налаштування tsconfig, ESLint, Prettier, автогенерація типів з OpenAPI/GraphQL.
3. Розробка строго типізованих компонентів і бізнес-логіки.
4. Code Review на наявність any, рефакторинг слабко типізованих місць.
5. Тестування з Vitest та інтеграційні тести.

Терміни та результати

• Тиждень 1: налаштування оточення, генерація типів.
• Тижні 2–3: розробка з повною типізацією.
• Тиждень 4: code review, тести, виправлення зауважень.

Проєкт здається з нульовими any у продакшен-коді та увімкненим strict: true. Винятки документуються явним коментарем. Економія бюджету на налагодженні сягає 30%, що для типового проєкту становить $15 000. Типізація API економить у середньому 2 години розробника на тиждень, що при середній ставці $50/год дає економію $5 200 на рік.

Що входить у проєкт

• Типізація всіх API-запитів на основі OpenAPI-схем.
• Налаштування tsconfig і ESLint для максимальної строгості.
• Автогенерація типів і типобезпечний HTTP-клієнт.
• Документація щодо використовуваних типів і патернів.
• Code Review і тести (Vitest).
• Передача доступу до репозиторію та CI/CD-пайплайну.

Наші рішення охоплюють TypeScript для сайту, забезпечуючи типізований веб-інтерфейс та використання ефективних патернів TypeScript. Виконаємо ваш проєкт під ключ за 4 тижні. У вартість входить повна типізація, налаштування CI/CD та документація. Оцініть свій проєкт безкоштовно — напишіть нам.

Замовте розробку фронтенду на TypeScript — отримайте стабільний і легко підтримуваний код. Зв'яжіться з нами для консультації щодо вашого проєкту.

Фронтенд-розробка 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 сторінок.

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