← Усі статті

Bulletproof React: як не втопитися в хаосі власного фронтенду

Структура за фічами, чотири типи стану та ESLint-межі — практичний огляд підходу Bulletproof React для продакшен-команд.

Теги
НовиниРозробкаReact
Bulletproof React: як не втопитися в хаосі власного фронтенду
Зміст

Коротко

Bulletproof React — це не бібліотека, а набір угод для великих React-проєктів: структура за фічами, жорсткі правила імпортів і явний поділ типів стану. Ідея проста: свобода React не повинна перетворюватися на хаос папок, і через два місяці ви все ще розумієте, «де що лежить».

Що сталося

В екосистемі React давно назрів запит на «дорослу» архітектуру без нав’язування одного стейт-менеджера. Bulletproof React відповідає практиками з реальних продакшен-кодових баз.

Ключові елементи підходу:

  • Структура за фічами — кожна фіча в своєму модулі з компонентами, хуками, API та типами. Спільне — у shared, склейка маршрутів — у app.
  • ESLint і межі імпортів — фіча A не тягне внутрішності фічі B напряму; лише публічний API шару. Це знижує зв’язність і спрощує рефакторинг.
  • Чотири типи стану:
    • UI State — локальний UI (модалки, таби, useState);
    • Application State — бізнес-логіка клієнта (часто Zustand/Context);
    • Server Cache — дані з API (React Query, SWR тощо);
    • URL State — фільтри, пагінація, вкладки в адресному рядку.
  • Безпека — токени в httpOnly-cookie, захист маршрутів і компонентів на кількох рівнях, а не лише «сховали кнопку в UI».

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

Чому це важливо

React навмисно не диктує структуру папок. У маленькому pet-проєкті це плюс. У команді з трьох людей і десятка фіч — мінус: кожен пише «як звик», і через півроку merge-конфлікти та страх чіпати чужий модуль стають нормою.

Bulletproof React не скасовує Redux, Zustand чи Context — він каже, коли який інструмент доречний. Server cache не дублюють у глобальний store «на всякий випадок». URL не розмазують по десятку useEffect.

Для тих, хто веде ERP-подібні інтерфейси чи довгоживучі адмінки, це ближче до інженерної дисципліни, ніж до модного стеку.

На практиці

Що можна зробити вже на наступному спринті:

  1. Виділити 1–2 фічі в окремі папки з index.ts як публічною межею; заборонити deep-imports через eslint-plugin-import або boundaries.
  2. Пройтися по стану: список екранів → для кожного позначити, що з чотирьох типів; прибрати дублі (наприклад, список замовлень і в React Query, і в Redux без причини).
  3. Зафіксувати в README або ADR коротке «як ми кладемо файли» — навіть одна сторінка знижує онбординг.
  4. Не копіювати сліпо — якщо проєкт на 5 екранів, повний Bulletproof може бути зайвим; беріть шари зі зростанням складності.

Якщо ви вже використовуєте Feature-Sliced Design або модульний моноліт на фронті, багато чого здасться знайомим — Bulletproof React ближче до прагматичного «мінімуму порядку» для React-команд.

Підсумок

Bulletproof React — про передбачуваність: структура, імпорти, стан і безпека описані явно, а не «як вийшло у автора репозиторію». Це не панацея, але гарний чеклист перед тим, як репозиторій знову стане лабіринтом.