Что произошло

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

Ключевые элементы подхода:

• Структура по фичам (feature-based) — каждая фича живёт в своём модуле с компонентами, хуками, 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 — про предсказуемость: структура, импорты, состояние и безопасность описаны явно, а не «как получилось у автора репозитория». Это не серебряная пуля, но хороший чеклист перед тем, как репозиторий снова станет лабиринтом.