Когда лучше использовать React Context?

Context стоит использовать, когда данные нужны многим компонентам на разных уровнях дерева, а меняются они редко. Это транспорт «окружения», а не универсальный стейт-менеджер.

Хорошие случаи для Context

• Тема оформления (light/dark) — нужна всем, меняется по клику раз в час.
• Текущий пользователь и права — читают шапка, меню, гарды маршрутов.
• Локаль и переводы, конфигурация, фиче-флаги.
• Инстансы сервисов — api-клиент, сокет, аналитика (вместо синглтонов — удобно мокать в тестах).
• Составные компоненты — <Tabs> делится состоянием с <Tab> через внутренний контекст.

Общий признак: данные глобальны для поддерева, обновления редкие, все потребители должны обновиться при изменении.

Когда Context — плохой выбор

• Часто меняющееся состояние (ввод в поля, позиция мыши/скролла, таймеры): каждое изменение value перерендеривает всех потребителей, селекторов «на кусочек» нет.
• Сложное взаимосвязанное состояние с множеством обновлений из разных мест — лучше Zustand/Redux с точечными подписками, devtools и middlware.
• Данные с сервера — это кеш, а не контекст: TanStack Query/SWR.
• Просто чтобы «не передавать проп на два уровня» — иногда достаточно композиции (children).

Практические правила

const value = useMemo(() => ({ user, logout }), [user, logout]);
<AuthContext.Provider value={value}>

• Мемоизировать value (иначе каждый рендер провайдера будит потребителей).
• Разделять контексты по частоте изменений (user отдельно от notifications).
• Держать state рядом: провайдер владеет useState/useReducer и отдаёт наружу и данные, и действия.

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

Context — для редко меняющихся данных, нужных многим уровням: тема, пользователь, локаль, сервисы. Не подходит для частых обновлений и сложного стора — все потребители рендерятся целиком. Правила: мемоизированный value, раздельные контексты, серверные данные — в React Query, а не в контекст.