Что такое Redux Toolkit

Redux Toolkit это официальный слой инструментов поверх Redux. Он не меняет саму модель Redux. По-прежнему есть store, actions, reducers, dispatch и чтение state. Главное отличие в том, что типовой код становится короче, а опасные места закрыты настройками по умолчанию.

Хороший короткий ответ на интервью может звучать так:

Redux Toolkit это рекомендуемый способ писать Redux сегодня. Он дает createSlice для reducer и actions, configureStore для настройки store и middleware, Immer для удобных иммутабельных обновлений и инструменты для async logic. Но я все равно выбираю, какое состояние действительно должно быть глобальным.

Такой ответ лучше простого перечисления API. Вы показываете практический вывод. Вы не просто знаете названия функций, а понимаете, зачем они нужны в реальном фронтенд-коде.

В классическом Redux легко получить много повторяющегося кода. Отдельно action type, отдельно action creator, отдельно reducer с switch, отдельно ручная настройка store и middleware. Чем больше такого кода, тем проще ошибиться в строковом action type или забыть подключить middleware.

В RTK типичный slice выглядит компактнее:

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

type CartItem = {
  id: string;
  title: string;
  count: number;
};

type CartState = {
  items: CartItem[];
};

const initialState: CartState = {
  items: [],
};

const cartSlice = createSlice({
  name: "cart",
  initialState,
  reducers: {
    addItem(state, action: PayloadAction<CartItem>) {
      state.items.push(action.payload);
    },
    clearCart(state) {
      state.items = [];
    },
  },
});

export const { addItem, clearCart } = cartSlice.actions;
export const cartReducer = cartSlice.reducer;

Здесь state.items.push выглядит как мутация, но это draft от Immer. Исходный Redux state не меняется напрямую. Практическая польза простая. Вам нужно меньше кода для копирования вложенных структур, и ниже риск случайно мутировать старое состояние.

configureStore помогает собрать store без ручной настройки большинства стандартных деталей. Он принимает объект reducer, добавляет thunk middleware, включает Redux DevTools и в development режиме помогает ловить типичные ошибки. Например случайные мутации, несериализуемые значения в actions или state, неправильное использование action creators.

Пример базовой настройки:

import { configureStore } from "@reduxjs/toolkit";
import { cartReducer } from "./cartSlice";

export const store = configureStore({
  reducer: {
    cart: cartReducer,
  },
});

export type RootState = ReturnType<typeof store.getState>;
export type AppDispatch = typeof store.dispatch;

Для TypeScript это важный плюс. Типы лучше выводить из реального store, а не описывать вручную. Так структура state не разъезжается между runtime кодом и типами.

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

Если состояние живет только в одном компоненте, например открыт ли локальный dropdown, глобальный store часто делает код сложнее. Если данные приходят с сервера и вам нужны кеш, invalidation, refetch и статусы запросов, это уже похоже на server state. В таком случае стоит отдельно упомянуть RTK Query или другую библиотеку для запросов.

Для async logic в Redux Toolkit часто используют createAsyncThunk. Он создает action lifecycle: pending, fulfilled и rejected. Это удобно, когда нужно явно хранить загрузку, ошибку и результат в slice.

Но важно не обещать лишнего. createAsyncThunk не делает полноценный кеш, не решает все race condition и не отменяет запросы за вас во всех сценариях. Если пользователь быстро переключает фильтры, старый ответ может прийти позже нового и перетереть список. UI покажет товары не по текущему фильтру, а аналитика может записать просмотр неправильного состояния. Безопаснее хранить currentRequestId, проверять его в fulfilled, использовать AbortSignal в thunk, condition для пропуска лишнего запроса или RTK Query для типичных server state сценариев.

Самая частая ловушка звучит так: RTK разрешает мутировать state. Если остановиться на этой фразе, ответ будет опасным. Лучше сказать точнее: внутри reducer из createSlice вы работаете с draft объектом, который дает Immer. По изменениям draft Immer строит новое иммутабельное состояние.

Плохой пример ответа:

В Redux Toolkit можно просто менять state напрямую, и Redux сам все поймет.

Лучше так:

В createSlice я могу писать код в мутирующем стиле, например state.count += 1. Но это не прямая мутация Redux state. Immer дает draft и на выходе создает новое состояние, поэтому сохраняется предсказуемость Redux.

Еще один нюанс: для объектного state удобно менять поля draft. Для примитивного state часто нужно вернуть новое значение, например return state + 1. Важно понимать контракт, а не просто запоминать синтаксис.

Сильный ответ удобно собрать в три шага. Сначала дайте определение: RTK это официальный набор инструментов для Redux. Потом назовите основные части: configureStore, createSlice, Immer, createAsyncThunk или RTK Query. В конце покажите границы. RTK снижает boilerplate и задает практики по умолчанию, но архитектуру состояния все равно нужно выбирать осознанно.

Если у вас есть опыт, добавьте короткий пример из проекта без лишних деталей:

Я использовал RTK для состояния корзины и пользователя, потому что эти данные нужны многим экранам. Локальный UI state, например открыта ли подсказка, оставлял в компонентах. Для API списка товаров выбрал RTK Query, потому что там были кеш и invalidation после изменения товара.

Замените пример на свой. Не выдумывайте RTK Query или сложную архитектуру, если вы с ними не работали. Можно честно сказать, что использовали createSlice и configureStore, а про RTK Query знаете как про инструмент для server state.