Что такое Redux, зачем он нужен и как устроен

Что проверяют

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

Как отвечать

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

Части: store с методами getState, dispatch и subscribe; действия как объекты с полем type; редьюсеры; middleware, через которое живёт асинхронность. Классический redux-thunk разрешает отправить функцию вместо объекта, она получает dispatch и getState и сама решает, когда и что отправить.

Сразу покажите современную запись:

const counter = createSlice({
  name: "counter",
  initialState: { value: 0 },
  reducers: { inc: (s) => { s.value += 1 } },
})
const store = configureStore({ reducer: { counter: counter.reducer } })

createSlice сам собирает типы действий, а мутирующий на вид код внутри Immer превращает в неизменяемое обновление.

Где спотыкаются

Показывают createStore и ручной switch, не зная, что этот вход помечен устаревшим, а рекомендуемый способ собрать стор это configureStore из Redux Toolkit.

Мутируют состояние в редьюсере вне Immer, например делают push в существующий массив. Ссылка на объект не меняется, сравнение по ссылке ничего не замечает, и компонент просто не перерисовывается.

Складывают в стор всё подряд: ответы сервера, состояние формы, флаги открытых модалок. Серверный кэш это задача RTK Query или похожей библиотеки, а на вопрос «нужен ли здесь Redux вообще» ожидают внятного ответа, потому что часто хватает состояния компонента и контекста.