Нужен ли стейт-менеджер?

Стейт-менеджер нужен не всегда: он оправдан при сложном общем состоянии, доступном многим компонентам; для локального или простого состояния достаточно встроенных средств.

Когда стейт-менеджер НЕ нужен

• Локальное состояние — useState/useReducer в компоненте.
• Небольшое приложение — состояние в паре компонентов, prop drilling терпим.
• Редко меняющееся общее состояние — хватает Context API (тема, локаль, юзер).
• Серверные данные — их лучше держать в TanStack Query/SWR, а не в глобальном сторе.

Когда стейт-менеджер нужен

• Сложное общее состояние, используемое многими несвязанными компонентами.
• Много источников изменений, трудно отследить, что и откуда меняет данные.
• Prop drilling стал болезненным.
• Нужны инструменты отладки, time-travel, middleware.
• Производный/кешируемый стейт, сложные обновления.

Частая ошибка

Тянуть Redux в маленький проект «на всякий случай» — избыточно. И наоборот: держать серверные данные в Redux вместо TanStack Query.

Как решить

1. Начать с useState/useReducer и подъёма состояния.
2. Общее редко меняющееся → Context.
3. Серверные данные → TanStack Query/SWR.
4. Если состояние реально сложное и глобальное → Redux Toolkit/Zustand.

Коротко для собеседования

Стейт-менеджер нужен при сложном общем клиентском состоянии со многими источниками изменений и болезненным prop drilling. Не нужен для локального (useState), редко меняющегося общего (Context) и серверных данных (TanStack Query). Не тянуть Redux в маленький проект «на всякий случай».