В каких случаях нужно использовать стейт-менеджер

Когда использовать State Manager

State management — это управление состоянием приложения. Вопрос не в том, нужен ли state manager, а в том, какой сложности состояния управлять и когда它 становится необходимым.

Когда НЕ нужен state manager

1. Маленькие приложения

// Простой Todo список
const App = () => {
  const [todos, setTodos] = useState([]);
  const [filter, setFilter] = useState('all');

  // Состояние простое и локальное
  // State manager излишен
};

2. Состояние чисто локальное

// UI состояние отдельного компонента
const Modal = () => {
  const [isOpen, setIsOpen] = useState(false);
  const [selectedTab, setSelectedTab] = useState('tab1');

  // Это дело компонента, не нужен глобальный state
};

3. Данные получены один раз

// Загрузили данные и показываем
const UserProfile = ({ userId }) => {
  const [user, setUser] = useState(null);

  useEffect(() => {
    fetch(`/api/users/${userId}`)
      .then(res => res.json())
      .then(setUser);
  }, [userId]);

  // Простой flow, state manager не нужен
};

Когда нужен state manager

1. Состояние используется в разных частях приложения

// Распределено по приложению
// Header нужны данные пользователя
// Sidebar нужны данные пользователя
// MainContent нужны данные пользователя
// Footer нужны данные пользователя

// Prop drilling на глубину 5+ уровней?
// Пора на state manager

const App = () => {
  const [user, setUser] = useState(null);

  return (
    <Header user={user} /> {/* prop 1 */}
    <Sidebar user={user} /> {/* prop 2 */}
    <MainContent user={user} /> {/* prop 3 */}
    <Footer user={user} /> {/* prop 4 */}
  );
};

// Лучше
const App = () => {
  // Redux, Zustand, Jotai — любой state manager
  return (
    <Provider>
      <Header />
      <Sidebar />
      <MainContent />
      <Footer />
    </Provider>
  );
};

2. Частые обновления состояния

// Фильтры, сортировка, пагинация, поиск
// Всё меняется часто и влияет на несколько компонентов

const ProductsPage = () => {
  // useState становится сложным
  const [filters, setFilters] = useState({});
  const [sort, setSort] = useState('date');
  const [page, setPage] = useState(1);
  const [search, setSearch] = useState('');
  const [results, setResults] = useState([]);
  const [loading, setLoading] = useState(false);

  // Слишком много состояния и зависимостей
  // Redux/Zustand упрощает логику
};

3. Сложная логика трансформации данных

// Множество зависимостей между данными
const DashboardPage = () => {
  // User данные
  const [user, setUser] = useState(null);
  // Products которые купил
  const [purchasedProducts, setPurchasedProducts] = useState([]);
  // Статистика
  const [stats, setStats] = useState(null);
  // Рекомендации
  const [recommendations, setRecommendations] = useState([]);
  // Уведомления
  const [notifications, setNotifications] = useState([]);

  // Множество useEffect'ов, которые зависят друг от друга
  // Это становится spaghetti code
};

4. Асинхронные операции

// Одна операция, несколько шагов
// Fetch → loading → success/error → retry

// С Redux очень просто
const UserForm = () => {
  const dispatch = useDispatch();
  const { loading, error, user } = useSelector(state => state.user);

  const handleSubmit = (data) => {
    dispatch(updateUser(data));
  };

  return (
    <form onSubmit={handleSubmit}>
      {loading && <Spinner />}
      {error && <Error message={error} />}
      {/* ... */}
    </form>
  );
};

5. Отмена операций и retry логика

// Нужно отменить запрос
// Нужно повторить с другими параметрами
// State manager решает это элегантнее чем useState

const SearchUsers = () => {
  const dispatch = useDispatch();
  const { results, loading } = useSelector(state => state.search);

  const handleSearch = (query) => {
    dispatch(searchUsers(query));
  };

  const handleCancel = () => {
    dispatch(cancelSearch());
  };

  const handleRetry = () => {
    dispatch(retryLastSearch());
  };
};

6. Time travel debugging

// Redux DevTools позволяет:
// - Видеть все экшены
// - Откатываться на любой момент
// - Воспроизводить ошибки

// Это полезно при сложном состоянии

7. Кеширование данных

// Один раз загруженные данные используются везде
// User загружен → сохраняем в store
// Любой компонент может взять без повторной загрузки

// Со useState нужно передавать props
// С state manager — выбираешь из store

Какой state manager выбрать?

Redux

// Для больших приложений
// Много инструментов и middleware
// Steep learning curve

const store = createStore(rootReducer);

Когда: 1000+ компонентов, сложная логика, большая команда

Zustand

// Лёгкий и быстрый
// Minimal API
import create from 'zustand';

const useStore = create((set) => ({
  count: 0,
  increment: () => set((state) => ({ count: state.count + 1 }))
}));

Когда: средние проекты, нужна простота

Jotai

// Атомарный подход
// Очень гибкий

const countAtom = atom(0);

const Counter = () => {
  const [count, setCount] = useAtom(countAtom);
};

Когда: гибкость важнее всего

Recoil

// От Facebook, похож на Jotai
// Экспериментальный

MobX

// Реактивный подход
// Автоматическое отслеживание зависимостей

class Store {
  @observable count = 0;

  @action increment = () => {
    this.count++;
  };
}

Когда: нравится OOP, автоматическое отслеживание

Критерии для выбора

Небольшое приложение
├─ Context API / useState
├─ Может быть Zustand если растёт
└─ Не нужен Redux

Средний проект (10-50 компонентов)
├─ Zustand или Jotai
├─ Context API если простое
└─ Redux если будет расти

Большой проект (100+ компонентов)
├─ Redux
├─ MobX
├─ Zustand + middleware
└─ Context API NO

Правило 80/20

• 80% проектов не нужен state manager
• useState + Context достаточны для большинства
• State manager нужен когда prop drilling и useEffect вилка усложняют код

Итог

• Начни с useState
• Когда prop drilling раздражает → Context API
• Когда логика усложняется → Zustand (лёгкий)
• Когда очень сложно → Redux (мощный)
• Не усложняй раньше времени