> В чем разница useReducer и useState в React (React)

Короткий ответ

useState - простой хук для управления одним значением, основан на прямом обновлении состояния. useReducer - более мощный инструмент для сложной логики, где состояние зависит от предыдущего значения и нескольких действий. Разница в уровне абстракции: useReducer использует reducer-функцию и dispatch, что даёт предсказуемость и тестируемость. Выбор зависит от сложности: для простых полей - useState, для комплексных объектов с разными сценариями - useReducer.

Подробное объяснение

useState и useReducer - оба хука для управления состоянием в React, но с разными подходами. useState возвращает кортеж [state, setState], где setState может принимать новое значение или функцию-обновление. Он идеален для изолированных значений: строк, чисел, булевых флагов. Когда состояние - простой примитив или объект с одним уровнем вложенности, useState даёт минимальный boilerplate.

useReducer принимает reducer-функцию и начальное состояние, возвращая [state, dispatch]. Reducer - чистая функция (state, action) => newState, где action - объект с типом и опциональными данными. Это паттерн из Redux, перенесённый в React. useReducer становится необходимым, когда:

• состояние - сложный объект с несколькими полями
• обновления зависят от предыдущего состояния
• есть несколько типов действий (например, add, remove, update)
• логика обновления выносится для переиспользования или тестирования

Ключевое различие - уровень контроля. useState скрывает детали обновления, useReducer явно описывает все возможные трансформации. Для простых случаев useReducer избыточен, для сложных - useState приводит к хаосу из вложенных setState и багов с замыканиями.

На практике

Выбор между хуками - trade-off между простотой и масштабируемостью. Для формы с 3 полями useState быстрее писать. Для корзины товаров с добавлением, удалением, изменением количества - useReducer даёт чистую архитектуру. Также useReducer полезен при передаче dispatch через context: дочерние компоненты могут отправлять действия без знания деталей состояния.

Производительность: оба хука оптимизированы, но useReducer может быть эффективнее при частых обновлениях сложного состояния, так как reducer - чистая функция без лишних ререндеров. Однако разница заметна только на больших объёмах данных.

На практике senior-разработчик выбирает useReducer, когда видит паттерн "много setState подряд" или когда состояние начинает "расползаться" по компоненту. Это сигнал к рефакторингу.

Пример кода

JSX
// useState - простое поле
const [count, setCount] = useState(0);
setCount(count + 1);

// useReducer - сложная логика
const initialState = { items: [], total: 0 };
function cartReducer(state, action) {
  switch (action.type) {
    case 'add':
      return { ...state, items: [...state.items, action.payload], total: state.total + action.payload.price };
    case 'remove':
      return { ...state, items: state.items.filter(item => item.id !== action.id), total: state.total - action.price };
    default:
      return state;
  }
}
const [cart, dispatch] = useReducer(cartReducer, initialState);
dispatch({ type: 'add', payload: { id: 1, name: 'Phone', price: 500 } });

Как отвечать на собеседовании

Начни с чёткого определения: useState для простых значений, useReducer для сложной логики. Приведи конкретный пример из практики, когда ты перешёл с useState на useReducer и почему. Упомяни, что оба хука решают одну задачу, но с разной степенью абстракции. Покажи понимание trade-off: boilerplate vs предсказуемость. Добавь про тестируемость reducer'ов и передачу dispatch через context. Не критикуй useState - это не плохой хук, а инструмент для своей задачи.

Что проверяет интервьюер

Интервьюер оценивает:

• понимание фундаментальных концептов React (состояние, ререндер, чистота функций)
• способность выбирать правильный инструмент под задачу
• знание паттернов управления состоянием (reducer pattern)
• опыт работы со сложными формами, списками, корзинами
• умение объяснять trade-off без фанатизма

Senior должен показать, что не просто знает синтаксис, а понимает, когда каждый хук даёт реальную пользу, а когда - лишнюю сложность.

Типичные ошибки

• Использовать useReducer для одного примитивного поля - избыточно и снижает читаемость
• Мутировать состояние в reducer'е - нарушение чистоты функции
• Создавать reducer внутри компонента - теряется переиспользование и тестируемость
• Путать useReducer с Redux - это разные уровни: хук для локального состояния, Redux для глобального
• Забывать про начальное состояние и lazy initialization
• Использовать useState для сложных объектов с глубокой вложенностью - приводит к ошибкам из-за неявного мутирования