До сих пор вопрос «как управлять состоянием» остаётся одним из самых обсуждаемых в экосистеме React. При этом многие команды выбирают инструмент не по задаче, а по хайпу и получают раздутую архитектуру, сложную отладку и технический долг.
На самом деле, правильный выбор зависит от типа состояния, а не от размера приложения.
Главный принцип: не всё состояние глобальное
Большинство проблем с управлением state возникают из-за неправильной классификации. Разделите состояние на три категории:
1. Локальное (UI-state)
- Открыто ли модальное окно?
- Текущая вкладка в табах?
- Состояние формы?
- Храните в useState внутри компонента.
2. Совместно используемое (feature-state)
- Данные профиля пользователя,
- Список проектов в sidebar’е,
- Фильтры в таблице.
- Поднимайте к ближайшему общему родителю или выносите в кастомный хук.
3. Глобальное (app-wide state)
- Авторизация (токен, роль),
- Тема (light/dark),
- Язык интерфейса,
- Кэш данных API.
- Только здесь нужны внешние менеджеры состояния.
💡 80% состояния — локальное или feature-level. Глобального не более 10–15%.
Если вы кладёте всё в Redux или Context — вы усложняете архитектуру без причины.
«Ничего» это лучший выбор для большинства случаев
Да, вы прочитали правильно.
React уже имеет встроенный менеджер состояния:
- useState для локального состояния,
- useReducer для сложной логики обновления,
- Поднятие состояния для совместного использования.
Пример: форма редактирования профиля
Плюсы:
- Минимальный бандл,
- Простая отладка,
- Легко тестируется,
- Не нужно думать о мемоизации, сериализации, devtools.
Используйте это по умолчанию, пока не появится реальная необходимость в другом.
Когда Context это плохая идея
React.createContext мощный инструмент, но часто используется неправильно.
Проблема:
Каждый раз, когда значение контекста меняется, все потребители (useContext) ререндерятся, даже если им нужна только часть данных.
Решение:
- Создавайте узкоспециализированные контексты:
- Храните в контексте только стабильные значения (например, через useMemo).
Когда Context уместен:
- Тема, язык, авторизация — то, что меняется редко.
- Инъекция зависимостей (например, apiClient).
Не используйте Context для:
- Часто обновляемых данных (фильтры, список элементов),
- Больших объектов без мемоизации.
Zustand: простота без компромиссов
Zustand это минималистичный, но мощный менеджер состояния, который стал стандартом де-факто.
Почему он популярен:
- Нет boilerplate’а (в отличие от Redux),
- Автоматическая мемоизация: компоненты подписываются только на нужные поля,
- Поддержка middleware (persistence, devtools, immer),
- Работает вне React (можно использовать в утилитах).
Пример:
В компоненте:
Используйте Zustand, если:
- У вас есть глобальное состояние, которое обновляется часто,
- Вы хотите избежать boilerplate’а Redux,
- Вам нужна простая интеграция с localStorage или devtools.
Redux Toolkit: когда он всё ещё актуален
Redux не умер он эволюционировал. Redux Toolkit (RTK) убрал 90% боли старого Redux.
Когда RTK оправдан:
- У вас сложная бизнес-логика с middleware,
- Требуется строгая типизация и предсказуемость (финансы, медицина, энтерпрайс),
- Вы используете RTK Query для управления данными API (альтернатива React Query).
Пример RTK Query:
Кэширование, рефетч, мутации — «из коробки».
Выбирайте RTK, если:
- Ваше приложение — это платформа, а не сайт
- У вас есть команда, готовая поддерживать слой Redux,
- Вы уже в экосистеме Redux (devtools, middleware).
Не выбирайте RTK, если:
- Вы делаете маркетинговый сайт, блог или простой SaaS,
- У вас нет времени на настройку store, slices, thun
Сравнительная таблица
Практические рекомендации
- Начинайте с React. Только когда появится боль (например, пропсы пробрасываются через 5 уровней) смотрите в сторону других решений.
- Не смешивайте подходы без причины. Один источник истины для одного типа данных.
- Измеряйте производительность. Zustand и Redux не спасут от плохой архитектуры.
- Документируйте, где что хранится. Особенно в больших командах.
Инструмент под задачу, а не наоборот
Лучший менеджер состояния это тот, которого вы не используете без необходимости.
React достаточно силён сам по себе. Zustand идеальный баланс для большинства приложений. Redux Toolkit для сложных систем. А контекст только для узких, стабильных данных.
Перестаньте думать: «Какой менеджер состояния выбрать?»
Начните думать: «Какой тип состояния у меня есть и где ему логично жить?»
Ответ на этот вопрос сэкономит вам месяцы рефакторинга, багов и споров в код-ревью.