Контекст с редьюсером

Редьюсер кладёт каждый переход в одно место — так что форма состояния и его правила живут вместе, а не разбросаны по потребителям. С useState каждый компонент, мутирующий корзину, заново реализует «есть ли этот товар? тогда увеличить, иначе добавить». Редьюсер делает переход именованной, исчерпывающей функцией; компоненты просто объявляют намерение через dispatch.

type CartItem = { id: string; qty: number };
type CartState = { items: CartItem[] };
type CartAction =
  | { type: "add"; id: string }
  | { type: "remove"; id: string }
  | { type: "clear" };

function cartReducer(state: CartState, action: CartAction): CartState {
  switch (action.type) {
    case "add": {
      const existing = state.items.find((i) => i.id === action.id);
      const items = existing
        ? state.items.map((i) => (i.id === action.id ? { ...i, qty: i.qty + 1 } : i))
        : [...state.items, { id: action.id, qty: 1 }];
      return { items };
    }
    case "remove":
      return { items: state.items.filter((i) => i.id !== action.id) };
    case "clear":
      return { items: [] };
  }
}

Редьюсер — чистая функция без React внутри — тривиально юнит-тестируемая, а размеченное объединение делает необработанное действие ошибкой типа. Правило «добавление увеличивает количество» теперь существует ровно один раз.

Раздавай state и dispatch через два отдельных контекста — не через один объект. Наивная версия — <CartContext.Provider value={{ state, dispatch }}>. Проблема: этот объект value — новая ссылка на каждом рендере, так что каждый потребитель перерисовывается, даже если он только и делает, что вызывает dispatch. Разделение позволяет компоненту подписаться ровно на то, что ему нужно.

const CartStateContext = createContext<CartState | null>(null);
const CartDispatchContext = createContext<React.Dispatch<CartAction> | null>(null);

export function CartProvider({ children }: { children: React.ReactNode }) {
  const [state, dispatch] = useReducer(cartReducer, { items: [] });
  return (
    <CartStateContext.Provider value={state}>
      <CartDispatchContext.Provider value={dispatch}>
        {children}
      </CartDispatchContext.Provider>
    </CartStateContext.Provider>
  );
}

Кнопка, которая только добавляет товары, читает контекст dispatch и никогда — контекст state, так что при изменении корзины эта кнопка не перерисовывается.

Контекст dispatch никогда не запускает перерисовки, потому что useReducer возвращает dispatch, чья идентичность стабильна на всё время жизни компонента. React гарантирует, что dispatch (как и обновляющая функция setState) ссылочно стабилен между рендерами. Контекст перерисовывает своих потребителей только тогда, когда value провайдера меняется по Object.is. Поскольку ссылка на dispatch никогда не меняется, value контекста dispatch никогда не меняется, а значит его потребители никогда не перерисовываются из-за него. Меняется только значение контекста state на каждое обновление, и перерисовываются только его читатели.

export function useCartDispatch() {
  const ctx = useContext(CartDispatchContext);
  if (!ctx) throw new Error("useCartDispatch must be used inside <CartProvider>");
  return ctx; // stable forever — safe to put in deps, safe to pass down
}

export function useCart() {
  const ctx = useContext(CartStateContext);
  if (!ctx) throw new Error("useCart must be used inside <CartProvider>");
  return ctx;
}

В этом весь трюк с эффективностью: писатели (триггеры действий) развязаны с читателями (отображениями состояния). В однотонной схеме с одним контекстом тебе пришлось бы хвататься за useMemo на значении и memo на детях, чтобы отыграть это назад; разделение даёт это структурно, бесплатно.

Знай режим отказа: этот паттерн — для умеренного клиентского состояния с настоящими переходами — не для серверного состояния и не для огромного / высокочастотного состояния. Два неверных применения топят его. Первое: положить сюда серверное состояние (каталог товаров, заказы пользователя) — значит вручную городить кэширование, перезапрос, протухание и дедупликацию, которые query-библиотека уже решает; у контекста + редьюсера нет понятия «эти данные пришли из сети и могут протухнуть». Второе: когда состояние велико или обновляется много раз в секунду (живой курсор, большой документ редактора, посимвольное состояние формы, читаемое сотнями узлов), даже подход с разделёнными контекстами перерисовывает каждого читателя состояния на каждое изменение, потому что контекст не умеет в избирательные подписки.

// WRONG: server state shoved into a reducer/context
dispatch({ type: "ordersLoaded", orders }); // who refetches? when is this stale?
// → use TanStack Query / SWR: useQuery(['orders', userId], fetchOrders)

// WRONG: high-frequency, selector-needing state in context
// every keystroke re-renders all 200 fields that read the form context
// → use an external store (Zustand/Redux + selectors, or useSyncExternalStore)

Контекст + редьюсер сидит посередине: больше, чем useState, поднятый на один уровень, меньше, чем стор. Подбирай его именно под эту полосу.