Редьюсеры и контекст: из разрозненных setState — в тестируемые переходы

Переходы, а не поля: что на самом деле меняет useReducer

У формы с десятью вызовами useState нет архитектуры — есть десять независимых значений и надежда, что каждый обработчик обновит нужное подмножество. Сценарий отказа — дрейф инварианта: правило вроде «итог отражает скидку и доставку» не живёт ни в одном конкретном месте, и каждый новый обработчик — шанс обновить четыре поля из пяти нужных. useReducer переворачивает структуру. Состояние становится одним объектом; обновления — экшенами, именованными событиями, описывающими, что произошло (promo-applied), а не какие поля записать (setDiscount + setTotal). Редьюсер — единственное место, где события превращаются в следующее состояние:

function checkoutReducer(state, action) {
  switch (action.type) {
    case "promo-applied": {
      const discount = computeDiscount(state.items, action.code);
      return withTotals({ ...state, promoCode: action.code, discount });
    }
    case "shipping-selected": {
      return withTotals({ ...state, shipping: action.method });
    }
    default:
      throw new Error(`Unknown action: ${action.type}`);
  }
}

// withTotals — ЕДИНСТВЕННОЕ место, где живёт инвариант:
function withTotals(state) {
  return { ...state, total: subtotal(state) - state.discount + shippingCost(state) };
}

const [state, dispatch] = useReducer(checkoutReducer, initialCheckout);
// Обработчики сжимаются до намерения: dispatch({ type: "promo-applied", code });

Механика: dispatch планирует ре-рендер, и React вызывает ваш редьюсер с текущим состоянием и экшеном при следующем рендере — поэтому редьюсер обязан быть чистым: никаких запросов, никакого Date.now(), никакой мутации входящего состояния (в StrictMode редьюсер вызывается дважды ровно затем, чтобы это поймать). Компоненты сжимаются до диспетчеризации намерений; логика решений покидает компонент целиком.

Чистая логика — тестируемая логика

Спросите себя: как написать регрессионный тест на баг, который проявляется только в определённой последовательности двух событий, без DOM? С редьюсером ответ — три строки. Поскольку редьюсер — чистая функция (state, action) => state, самая баго-опасная логика фичи — многопольные инварианты, последовательности краевых случаев — становится юнит-тестируемой без рендеринга чего-либо. Регрессионный тест из Hook — три строки проигрывания: стартуем с известного состояния, диспатчим shipping-estimate-loaded, затем promo-applied, проверяем итог. Без JSDOM, без act(), без замоканной сети — тесты редьюсера выполняются за микросекунды и прибивают последовательности, а именно там прячутся баги разрозненных setState. Это недооценённый выигрыш: команды берут редьюсеры «для порядка», а обнаруживают, что главный приз — логика состояния наконец получает ту же тестовую дисциплину, что и остальная кодовая база. Компромисс: церемония реальна — типы экшенов, switch, прослойка между кликом и записью. Для двух полей без инвариантов useState строго лучше; редьюсер окупается, когда поля обновляются вместе по правилам.

Разделение state и dispatch: гигиена ре-рендеров как архитектура

Чтобы раздать состояние редьюсера по поддереву фичи, его передают через контекст — и тут гигиена ре-рендеров из юнита 02 становится архитектурным решением. Контекст ре-рендерит каждого потребителя, когда идентичность его значения меняется. Если публиковать { state, dispatch } одним объектом, каждый потребитель ре-рендерится на каждое изменение состояния — включая кнопки тулбара, которые только диспатчат. Лечение структурное: два контекста.

const CheckoutStateContext = createContext(null);
const CheckoutDispatchContext = createContext(null);

function CheckoutProvider({ children }) {
  const [state, dispatch] = useReducer(checkoutReducer, initialCheckout);
  return (
    <CheckoutDispatchContext.Provider value={dispatch}>
      <CheckoutStateContext.Provider value={state}>
        {children}
      </CheckoutStateContext.Provider>
    </CheckoutDispatchContext.Provider>
  );
}

React гарантирует, что dispatch ссылочно стабилен между рендерами — значение dispatch-контекста никогда не меняется, поэтому компоненты «только записи» (кнопки, пункты меню, баннер экспресс-чекаута) подписываются на него и никогда не ре-рендерятся от изменений состояния. Читающие компоненты подписаны на state-контекст и ре-рендерятся при изменении состояния — честно, ведь они его отображают.