Как определить, нужен ли стейт-менеджер

Стейт-менеджер нужен не потому, что приложение стало большим. Он нужен, когда у состояния появилась широкая область жизни, несколько мест изменения и риск рассинхронизации. На интервью лучше начинать не с названия библиотеки, а с типа состояния.

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

Удобная формулировка для интервью может звучать так:

Я начинаю с самого простого варианта, который покрывает текущую область состояния. Если состояние локальное, оставляю его рядом с компонентом. Если оно становится общим, часто меняется из разных мест или требует предсказуемого сценария обновления, выношу его в store. Отдельно не смешиваю server cache и client state.

Такая формулировка звучит сильнее, чем простой ответ про Redux. Она показывает, что вы выбираете инструмент под проблему, а не по привычке.

Во frontend обычно есть несколько разных типов состояния.

Локальное UI-состояние живет рядом с компонентом. Например, открыта ли модалка, выбран ли tab, что введено в поле до отправки. Если это не нужно другим независимым частям приложения, не переносите такое состояние в глобальный store заранее.

Общее клиентское состояние связано с поведением продукта. Это корзина, авторизация, шаг мастера, настройки конструктора, выбранные фильтры, если они влияют на несколько экранов. Здесь store может помочь, потому что появляется один источник правды.

Server state это данные, которые пришли с backend. У них есть загрузка, ошибка, устаревание, повторный запрос, отмена запроса и invalidation. Если вручную держать все это в store, легко получить устаревший UI, лишний запрос, гонку запросов и дублирование логики. Безопаснее использовать cache слой для server state. А в store хранить только то, что реально принадлежит клиентскому сценарию: выбранные фильтры, шаг мастера, черновик до отправки.

Плохой сигнал для выбора store: у нас есть форма, значит нужен Redux. Если форма живет на одном экране, начните проще.

function ProfileForm() {
  const [name, setName] = useState("");
  const [isSubmitting, setSubmitting] = useState(false);
  const [error, setError] = useState<string | null>(null);

  async function handleSubmit(event: React.FormEvent<HTMLFormElement>) {
    event.preventDefault();
    setSubmitting(true);
    setError(null);

    try {
      await saveProfile({ name });
    } catch {
      setError("Could not save profile");
    } finally {
      setSubmitting(false);
    }
  }

  return (
    <form onSubmit={handleSubmit}>
      <label htmlFor="profile-name">Name</label>
      <input
        id="profile-name"
        name="name"
        value={name}
        onChange={(event) => setName(event.target.value)}
      />
      {error ? <p role="alert">{error}</p> : null}
      <button type="submit" disabled={isSubmitting}>
        {isSubmitting ? "Saving..." : "Save"}
      </button>
    </form>
  );
}

Здесь глобальный store не дает пользы. Он только отдалит состояние от места использования и усложнит тесты. Важно не терять базовые детали UI: обработчик submit, disabled на время отправки, error state и label для поля. Store не исправит плохую доступность, скрытую ошибку сохранения или повторную отправку формы сам по себе.

Другой случай: корзина показывается в header, меняется на странице товара, проверяется на checkout и влияет на аналитику. Если каждая часть хранит свою копию, пользователь увидит разные суммы или потеряет товар после перехода. Здесь нужен общий источник правды.

const useCartStore = create((set) => ({
  items: [],
  addItem: (item) =>
    set((state) => ({
      items: [...state.items, item],
    })),
  clear: () => set({ items: [] }),
}));

Пример показывает идею, а не обязательный выбор Zustand. В Redux, MobX или другом инструменте критерий тот же: состояние общее, изменяется из разных мест и должно оставаться согласованным.

Context удобен для значений, которые нужны глубоко в дереве: тема, язык, текущий пользователь, feature flags. Но если положить в один provider часто меняющийся объект, можно случайно подписать половину приложения на каждое изменение.

Опасный вариант:

<AppContext.Provider value={{ user, cart, filters, setCart, setFilters }}>
  <App />
</AppContext.Provider>

Проблема не в самом Context, а в слишком широком контракте. Без разделения и стабильных ссылок изменение фильтра может затронуть компоненты, которым нужен только пользователь. Пользователь увидит задержки в вводе, лишние рендеры списка или мигание loading там, где данные не менялись. Безопаснее разделять контексты по смыслу, мемоизировать value или использовать store с селекторами, если обновлений много.

<UserContext.Provider value={userValue}>
  <CartContext.Provider value={cartValue}>
    <FiltersContext.Provider value={filtersValue}>
      <App />
    </FiltersContext.Provider>
  </CartContext.Provider>
</UserContext.Provider>

Так компоненты подписываются на свой тип данных, а не на один общий объект приложения.

Не говорите, что стейт-менеджер сам ускоряет приложение. Лучше объяснить механизм. Производительность улучшается, когда компонент подписан только на нужный кусок state, селектор возвращает стабильное значение, а обновление не задевает всю страницу.

При этом store может и ухудшить ситуацию. Если хранить большой объект и подписывать компоненты на него целиком, каждое изменение будет создавать новые ссылки и лишние рендеры. Поэтому сильный ответ включает не только выбор библиотеки, но и структуру данных, селекторы и границы подписки.