Зачем нужен менеджер состояния в React?
Контекст и State managers
Менеджер состояния нужен, когда состояние перестаёт быть локальным: много несвязанных компонентов читают и меняют одни данные, и встроенных средств React становится мало.
Проблемы, которые он решает
Общие данные без акробатики. Корзина нужна шапке, каталогу и чекауту. Средствами React: поднять state к общему предку → прокинуть props через десяток уровней (или контекст, который будит всех потребителей). Со стором: const items = useCart((s) => s.items) в любом месте.
Точечные подписки. Селекторы перерисовывают только компоненты, чьи данные изменились, — в отличие от контекста (все потребители целиком).
Централизованная логика. Правила обновления (пересчёт итога, лимиты, синхронизации) живут в одном месте — сторе/редьюсерах, а не размазаны по обработчикам компонентов; тестируются без UI.
Предсказуемость и отладка. Однонаправленный поток (action → изменение → подписчики), Redux DevTools: история действий, time travel, снапшоты — «кто и когда изменил состояние» видно.
Жизнь вне дерева. Стор переживает размонтирование компонентов; к нему есть доступ из не-React кода (интерцепторы, сокеты).
Когда он НЕ нужен
- Локальное состояние (формы, модалки, табы) — useState.
- Серверные данные — React Query/SWR (кеш с инвалидацией, а не стор).
- Редко меняющееся «окружение» (тема, юзер) — Context.
Многим приложениям хватает useState + Context + React Query; стор подключают для действительно общего и динамичного клиентского состояния (корзина, редактор, realtime).
Коротко для собеседования
Стейт-менеджер нужен для общего клиентского состояния многих несвязанных компонентов: доступ без prop drilling, точечные подписки селекторами, централизованная тестируемая логика, девтулзы с историей. Не нужен для локального состояния (useState), серверных данных (React Query) и редких глобалок (Context).