> Какие глобальные state менеджеры существуют для React (React)

Короткий ответ

Основные глобальные state-менеджеры для React: Redux (с Redux Toolkit), MobX, Zustand, Recoil, Jotai, Valtio, а также Context API + useReducer для простых случаев. Для server state - React Query, SWR, Apollo Client. Выбор зависит от сложности приложения, необходимости в middleware, типизации и предпочтений команды.

Подробное объяснение

Глобальные state-менеджеры решают проблему передачи данных между компонентами без проп-дриллинга. Они делятся на категории:

Client state (локальное состояние приложения):

• Redux Toolkit - наиболее популярный, основан на flux-архитектуре, immutable updates, middleware (thunk, saga). Хорош для крупных приложений с сложной логикой.
• MobX - использует observable, mutable подход, автоматически отслеживает зависимости. Проще в освоении, но менее предсказуем.
• Zustand - минималистичный, без boilerplate, на основе hooks. Идеален для средних проектов.
• Recoil/Jotai/Valtio - атомарные менеджеры, где состояние разбито на атомы. Recoil от Meta, Jotai и Valtio от сообщества. Удобны для изолированных состояний.
• Context API + useReducer - встроенное решение, подходит для простых глобальных состояний (тема, авторизация), но имеет проблемы с производительностью при частых обновлениях.

Server state (данные с сервера):

• React Query (TanStack Query) - управляет кэшированием, синхронизацией, ревалидацией данных с API.
• SWR - от Vercel, похож на React Query, легковеснее.
• Apollo Client - для GraphQL.

Trade-offs:

• Redux: мощный, но много boilerplate (даже с Toolkit), требует строгой архитектуры.
• Zustand: простой, но нет встроенной поддержки side effects.
• Recoil: экспериментальный, может иметь проблемы с производительностью.
• Context API: не оптимизирован для частых обновлений, вызывает ререндеры всех потребителей.

На практике

Для нового проекта с нуля:

• Если приложение простое (до 10 страниц) - Zustand или Context API.
• Если среднее (сложная бизнес-логика, много форм) - Redux Toolkit + RTK Query.
• Если данные с сервера преобладают - React Query + Zustand для локального состояния.
• Для микросервисной архитектуры - Jotai или Valtio.

При миграции с Redux на что-то другое - оценивай количество middleware, thunk/saga, типизацию. Zustand легко интегрируется с TypeScript.

Пример кода

TYPESCRIPT
// Zustand store
import { create } from 'zustand';

interface CounterState {
  count: number;
  increment: () => void;
  decrement: () => void;
}

const useCounterStore = create<CounterState>((set) => ({
  count: 0,
  increment: () => set((state) => ({ count: state.count + 1 })),
  decrement: () => set((state) => ({ count: state.count - 1 })),
}));

// В компоненте
function Counter() {
  const { count, increment, decrement } = useCounterStore();
  return (
    <div>
      <button onClick={decrement}>-</button>
      <span>{count}</span>
      <button onClick={increment}>+</button>
    </div>
  );
}

Как отвечать на собеседовании

Начни с категоризации: client vs server state. Перечисли основные инструменты, кратко опиши их сильные и слабые стороны. Упомяни, что выбор зависит от контекста: размер приложения, требования к производительности, опыт команды. Приведи пример, когда ты выбирал конкретный менеджер и почему. Избегай субъективных оценок вроде "Redux умер" - это непрофессионально.

Что проверяет интервьюер

• Понимание различий между client и server state.
• Знание современных инструментов (не только Redux).
• Умение оценивать trade-offs.
• Практический опыт: когда какой инструмент уместен.
• Понимание проблем производительности (ререндеры, мемоизация).

Типичные ошибки

• Называть только Redux и Context API, игнорируя Zustand, Jotai, React Query.
• Путать server state менеджеры (React Query) с client state (Redux).
• Говорить, что Context API - полноценная замена Redux (это не так для сложных приложений).
• Не упоминать про производительность и ререндеры.
• Давать однозначный ответ без анализа контекста.