Что такое Redux

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

Базовые части такие: store хранит state, action описывает, что произошло, dispatch отправляет action, reducer вычисляет новое состояние. Компоненты обычно читают данные через selectors, а не залезают в структуру store напрямую.

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

Главная идея Redux не в том, что state глобальный. Главная идея в контролируемом потоке изменений. Это снижает риск, что один компонент незаметно изменит данные, а другой покажет устаревший UI.

Опасный flow обычно ломает не архитектурную красоту, а поведение интерфейса. Пользователь может увидеть старую корзину, повторную отправку формы, исчезнувшую ошибку или список из ответа на предыдущий фильтр. Безопаснее держать изменение состояния в одном месте, а побочные эффекты выносить из reducer.

Пример на современном Redux обычно лучше показывать через Redux Toolkit. Он убирает большую часть ручного бойлерплейта, но сохраняет те же идеи: action, reducer, store и dispatch.

import { configureStore, createSlice } from "@reduxjs/toolkit";
import type { PayloadAction } from "@reduxjs/toolkit";

const todosSlice = createSlice({
  name: "todos",
  initialState: [] as string[],
  reducers: {
    todoAdded(state, action: PayloadAction<string>) {
      state.push(action.payload);
    },
  },
});

export const { todoAdded } = todosSlice.actions;

export const store = configureStore({
  reducer: {
    todos: todosSlice.reducer,
  },
});

store.dispatch(todoAdded("Купить молоко"));

В этом примере state.push выглядит как мутация, но внутри createSlice это безопасно за счет Immer. Если вы пишете классический reducer без Redux Toolkit, нужно возвращать новый массив или объект вручную. Это важная деталь, потому что фраза "Redux всегда запрещает такой синтаксис" будет неточной.

Хороший ответ не должен звучать как реклама Redux. Покажите, что вы выбираете инструмент по сложности состояния. Если state живет рядом с одним компонентом, Redux часто только увеличит цену изменения.

Сильная формулировка может быть такой:

Я бы не ставил Redux по умолчанию. Сначала смотрю, насколько состояние общее, сколько мест его меняет, нужны ли DevTools, кэш, статусы запросов и повторяемая отладка. Если это локальный UI-state, оставлю его в компоненте. Если это общий доменный state с несколькими сценариями изменения, Redux или Redux Toolkit может быть оправдан.

Такой ответ звучит спокойнее, чем "Redux устарел" или "Redux нужен всегда". Он показывает, что вы понимаете trade-off.

Redux сам по себе не говорит, что reducer может делать запросы. Reducer должен быть чистым: получил state и action, вернул новое состояние. Запросы к API, таймеры, навигация, запись в storage и аналитика являются побочными эффектами.

Для async-сценариев обычно используют middleware, createAsyncThunk, listener middleware или RTK Query. Во frontend-коде важно явно хранить статус: idle, loading, succeeded, failed. Иначе пользователь может увидеть пустой экран без ошибки, двойной spinner или данные от старого запроса.

Если запрос зависит от фильтра, id страницы или ввода пользователя, продумайте гонки. Старый ответ не должен перезаписывать новые данные. Обычно помогают отмена через AbortController, проверка актуального requestId или инструмент, который делает это за вас. При уходе со страницы не надо диспатчить обновление для уже неактуального экрана.

Если вы упоминаете optimistic UI, добавьте rollback. Без отката при ошибке API пользователь увидит действие как успешное, хотя сервер его не сохранил. Это уже не просто архитектурный спор, а риск потери доверия к интерфейсу.

Redux не означает, что весь state надо сложить в один огромный объект без правил. На практике состояние делят по slices: пользователь, корзина, задачи, настройки. Компоненты читают не сырые вложенные поля, а selectors.

Selectors полезны по двум причинам. Во-первых, компонент меньше зависит от внутренней формы store. Во-вторых, вычисления можно мемоизировать, чтобы не провоцировать лишние рендеры. Это особенно важно, если список большой или derived data собирается из нескольких частей state.

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

Не используйте Redux как сейф для чувствительных данных. Любой state на клиенте потенциально доступен JavaScript-коду на странице, расширениям и DevTools. Если в приложении есть XSS, токен в Redux станет легкой целью. Практичнее хранить в Redux только то, что нужно UI, и отдельно продумывать auth-хранилище, cookie-настройки и отсутствие секретов в логах actions.

На вопрос "Что такое Redux" отвечайте в три шага. Сначала дайте определение: библиотека для предсказуемого управления состоянием. Затем назовите механизм: store, actions, dispatch, reducers, selectors. Потом добавьте критерий выбора: полезен для сложного общего состояния, но не для каждого локального флага.

Если хотите усилить ответ, упомяните Redux Toolkit. Это покажет, что вы знаете современную практику и не застряли на старом ручном коде с createStore, action constants и большим количеством boilerplate.