Команда фронтенд-розробників впровадила типізований шар для мокінгу API, який існує лише під час розробки. Завдяки інтерцепторам Axios та tree-shaking у Vite, продакшн-бандл залишається незмінним. Інженери отримують дані за допомогою своїх звичних патернів, поки чекають на готовність ендпоінтів бекенду, а потім просто перемикають один прапорець середовища, щоб звертатися до реального API.

Чому команді знадобився кращий спосіб мокінгу

Фронтенд-розробники стикаються з перешкодами, коли маршрут бекенду ще не готовий. Швидке рішення — хардкодинг відповіді всередині компонента або розкидання блоків if (process.env.NODE_ENV === 'development') по всьому UI — дозволяє програмі працювати далі, але створює технічний борг. Ці моки стають частиною логіки компонента, підвищують ризик відправки фейкових даних у продакшн і ускладнюють читання та тестування коду.

Команда хотіла винести всі моки за межі дерева компонентів, забезпечити контракт між фронтендом і бекендом і гарантувати, що в продакшн-збірку не потрапить нічого зайвого.

Триетапний процес, якого дотримується команда

  1. Зустріч щодо контракту – Фронтенд- та бекенд-інженери сідають разом і перелічують кожен запит, його URL, метод та очікуваний payload.
  2. Типізований контракт – Вони перетворюють цей список на інтерфейс TypeScript, який стає єдиним джерелом істини для структур запитів і відповідей.
  3. Підключення інтерцептора – Інтерцептор Axios перевіряє кожен вихідний запит. Якщо URL збігається з зареєстрованим моком, інтерцептор повертає мок-дані; в іншому випадку запит спрямовується на живий сервер.

Оскільки інтерцептор — це єдине місце, де живе логіка мокінгу, код компонентів залишається незмінним. Розробники продовжують використовувати свої звичні хуки для отримання даних — наприклад, useQuery — без додавання будь-якої умовної логіки.

Як уникнути роздування продакшн-збірки

Команда впровадила три захисних механізми, які дозволяють Rollup (бандлеру, що використовується у Vite) повністю видалити код моків під час збірки для продакшну:

  • import.meta.env.DEV перетворюється на false у продакшн-збірці, тому весь модуль інтерцептора зникає під час tree-shaking.
  • Змінна MODE встановлюється на значення, відмінне від test, під час запуску юніт-тестів, що дозволяє відокремити код, необхідний лише для тестування.
  • Спеціальний прапорець VITE_ENABLE_MSW за замовчуванням має значення false і має бути явно увімкнений для активації моків.

Коли всі три умови є хибними (false), реєстр моків ніколи не потрапляє у фінальний бандл.

Організація файлів моків

Репозиторій має структуру, орієнтовану на фічі:

  • interfaces/ – Містить визначення TypeScript, згенеровані на основі зустрічі щодо контракту.
  • scenarios.ts – Містить конкретні приклади успішних відповідей та випадків помилок для кожного ендпоінту.
  • devHandlers.ts – Виступає центральним реєстром, який зіставляє URL із даними сценаріїв і підключає інтерцептор до Axios.

Невеликий скрипт для створення заготовок (scaffolding script) може генерувати ці файли автоматично: надайте йому URL та відповідний інтерфейс, і він створить файли-заглушки та зареєструє мок. Скрипт знаходиться поза шляхом продакшн-коду, тому він не впливає на розмір бандла.

Що отримала команда

  • Жодних моків всередині компонентів – Усі фейкові дані живуть у виділеному шарі, що дозволяє тримати код UI чистим.
  • Сквозна типізація – Мок-дані відповідають тим самим інтерфейсам TypeScript, що використовуються для реальних відповідей, тому невідповідності виявляються на етапі компіляції.
  • Відсутність зайвої ваги в продакшні – Tree-shaking повністю видаляє інтерцептор і мок-дані, не змінюючи розмір бандла.
  • Спільні сценарії для розробки та тестування – Ті самі визначення моків використовуються як для локальної розробки, так і для автоматизованих тестів, що зменшує дублювання.

Компроміси та обмеження

Цей підхід не замінює реальний бекенд. Якщо контракт мока розходиться з реальним API, розробники виявлять невідповідність лише після того, як перемкнуть прапорець середовища.

На що звернути увагу далі

  • Інтеграція з інструментами –
  • Широке впровадження –
  • Моніторинг продуктивності –

Висновок очевидний: перенесення логіки мокінгу в типізований шар, керований середовищем, дозволяє командам фронтенд-розробки тримати компоненти чистими, забезпечувати типізацію та випускати продакшн-збірки без прихованих мок-даних. Підтримка спільного контракту — це ціна більш плавного робочого процесу розробки та чистішого коду.