Для чего нужен Redux

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

Коротко можно ответить так:

Redux нужен, чтобы сделать изменения общего состояния предсказуемыми. Вместо того чтобы компоненты меняли данные как попало, мы описываем событие через action, reducer считает новое состояние, а компоненты читают нужный кусок через selector.

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

У Redux однонаправленный поток данных. UI не должен напрямую менять состояние. Компонент отправляет событие, а состояние меняется через reducer.

// Упрощенный пример с Redux Toolkit
import { createSlice } from "@reduxjs/toolkit";

const cartSlice = createSlice({
  name: "cart",
  initialState: { items: [] as string[] },
  reducers: {
    itemAdded(state, action) {
      state.items.push(action.payload);
    },
  },
});

export const { itemAdded } = cartSlice.actions;
export default cartSlice.reducer;

Здесь важно проговорить нюанс. В Redux Toolkit код внутри reducer выглядит как mutation, но это работает из-за Immer. Снаружи состояние остается иммутабельным. Нельзя брать объект из store в компоненте и менять его напрямую.

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

Типичные признаки такие: одни и те же данные нужны на разных экранах, изменения приходят из разных действий пользователя, нужно восстанавливать состояние после операций, важна отладка событий, есть сложные derived data через selectors.

Пример: корзина интернет-магазина. Ее меняют карточки товаров, страница корзины, промокоды, авторизация и восстановление сессии. Если держать это в локальном состоянии разных компонентов, легко получить рассинхрон UI, неверную сумму или потерю данных при переходе между страницами.

Context API часто сравнивают с Redux, но это не полная замена. Context хорошо передает значение через дерево компонентов: тему, язык, текущего пользователя, feature flags. Но Context сам по себе не дает actions, reducers, middleware, DevTools и соглашений для сложного изменения состояния.

Еще одна граница, которую стоит проговорить, это server state. У данных с API есть cache, loading, error, retry, refetch, invalidation и устаревание. Если вы вручную складываете каждый ответ API в Redux, можно получить устаревшие данные и лишние запросы.

Сильный ответ звучит гибко: Redux для сложного client state, Context для простой передачи стабильных значений, RTK Query или похожий инструмент для server state, если главная сложность в запросах и cache.

Redux делает состояние заметнее, но не отменяет обычные проблемы интерфейса. Если запросы ведутся вручную, явно думайте про loading, error, empty state, отмену ненужного запроса и защиту от старого ответа.

Плохой сценарий: пользователь быстро открывает профиль A, потом профиль B, а медленный ответ A приходит последним и перезаписывает экран. В UI будет показан не тот пользователь. Безопаснее привязывать ответ к текущему id, отменять старый запрос через AbortController или использовать RTK Query, где cache key и устаревание данных контролируются явно.

Еще один частый риск это производительность selector. Такой код выглядит невинно, но может давать лишние render:

const userView = useSelector((state) => ({
  name: state.user.name,
  role: state.user.role,
}));

Объект создается заново при каждом вызове selector. Если компонент тяжелый, UI начнет тормозить. Лучше выбрать поля отдельно, передать shallowEqual или собрать derived data через мемоизированный selector.