Error boundary: страховка только из классов и её четыре слепые зоны

Почему React размонтирует всё — и что такое boundary

React 16 принял осознанное решение: испорченный UI хуже, чем отсутствие UI. Если рендер бросил исключение и никто его не поймал, React не может знать, какая часть закоммиченного дерева теперь врёт пользователю — платёжная форма может показывать не ту сумму, медицинский дашборд — не того пациента. Поэтому он размонтирует весь корень. Error boundary — это ваш способ вернуть частичную живучесть: компонент, который говорит React «если что-то ниже меня бросит во время рендера, я отрисую что-то осмысленное вместо этого».

Boundary — это классовый компонент, реализующий один или оба из двух lifecycle-методов, и они делят работу по фазам render/commit:

class WidgetBoundary extends React.Component {
  state = { error: null };

  static getDerivedStateFromError(error) {
    // фаза рендера: должен быть чистым — вывести fallback-состояние, и ничего больше
    return { error };
  }

  componentDidCatch(error, errorInfo) {
    // фаза коммита: side-эффекты разрешены — отчитаться один раз, вместе с React-деревом
    reportError(error, errorInfo.componentStack);
    // componentStack выглядит так: "in PriceTag / in Card / in Carousel / in App"
  }

  render() {
    if (this.state.error) return <CarouselFallback />;
    return this.props.children;
  }
}

getDerivedStateFromError(error) выполняется в фазе рендера, пока React раскручивает стек после исключения — он обязан быть чистым, и его задача — вернуть состояние, переключающее render() на ветку фолбэка. componentDidCatch(error, errorInfo) выполняется в фазе коммита, где side-эффекты легальны — именно туда относится репортинг, и только он получает errorInfo.componentStack: цепочку компонентов, в которых жил краш, — это не то же самое, что JS-стек (цепочка вызовов функций, которая его породила). В отчёте обычно нужны оба.

Почему только классы? Потому что перехват исключения фазы рендера требует lifecycle-метода, который reconciler может вызвать синхронно посреди раскрутки стека. У функционального компонента такой точки крепления нет — всё его тело и есть рендер, и некуда повесить catch, не перезапустив тело целиком. Hook-эквивалента не существует, и документация React говорит об этом прямо. Каждый «функциональный boundary», который вы видели, внутри оборачивает класс.

Четыре слепые зоны

Boundary ловит ошибки, брошенные во время рендера, в lifecycle-методах и в конструкторах дерева под ним. Всё остальное ускользает, и эти четыре пути удивляют команды в проде. Прежде чем поставить boundary вокруг виджета, спросите себя: где именно живёт то, что с наибольшей вероятностью упадёт — в рендере, в хендлере, в async-коде или в самом фолбэке?

1. Хендлеры событий. Исключение в onClick происходит вне рендера — React нечего чинить в дереве, поэтому boundary вообще не участвует. Ошибка улетает в window как непойманное исключение, UI остаётся ровно каким был, а пользователь получает кнопку, которая «ничего не делает». try/catch — ваша обязанность.
2. Асинхронный код. Колбэки setTimeout, цепочки промисов, тело async-эффекта — к моменту исключения стек рендера давно исчез. Отклонённые промисы всплывают как unhandledrejection, а не как пойманная ошибка рендера.
3. Серверный рендеринг. Классовые boundary — механизм клиентского рантайма. При стриминговом SSR ошибку обрабатывают серверная точка входа (onError стримингового API) и ближайший Suspense-фолбэк — не ваш componentDidCatch.
4. Сам boundary. Исключение в собственном рендере boundary — чаще всего внутри навороченного фолбэка — улетает к следующему boundary выше. Если фолбэк корневого boundary тянет переводы и этот код бросает, вы снова на белом экране. Фолбэки обязаны быть скучными намеренно.

Все четыре категории вместе означают одно: boundary — не полная стратегия, а защита только пути рендера. Каждый другой путь требует явной обработки; пропустите хотя бы один — получите молча мёртвый UI при зелёном дашборде.

У первых двух слепых зон есть практичный мост. Де-факто стандартная обёртка, react-error-boundary, упаковывает класс за вас и добавляет примитив маршрутизации:

import { ErrorBoundary, useErrorBoundary } from "react-error-boundary";

function ExportButton() {
  const { showBoundary } = useErrorBoundary();
  return (
    <button
      onClick={async () => {
        try {
          await exportReport();   // хендлер + async: две слепые зоны разом
        } catch (err) {
          showBoundary(err);      // направить ВНУТРЬ ближайшего boundary
        }
      }}
    >
      Экспорт
    </button>
  );
}

<ErrorBoundary
  FallbackComponent={ReportFallback}  // получает { error, resetErrorBoundary }
  onError={(error, info) => reportError(error, info.componentStack)}
>
  <ReportPanel />
</ErrorBoundary>

showBoundary(err) заставляет ближайший boundary отрисовать фолбэк так, будто ошибка случилась в рендере — единый путь фолбэка и для крашей рендера, и для сбоев, пойманных вручную. onError централизует репортинг, чтобы каждый boundary не изобретал его заново.

Размещение: ярус роутов плюс ярус виджетов

Где ставить boundary — это решение о доступности: каждый boundary задаёт радиус поражения и должен пользователю осмысленный фолбэк:

• Корневой ярус — последний рубеж. Фолбэк — полностраничный экран «что-то сломалось, перезагрузите». Радиус всё ещё 100%, но спроектированные 100% вместо белого экрана. Каждому приложению нужен ровно один.
• Ярус роутов — по boundary на страничный маршрут. Каркас, навигация и остальные роуты живут; фолбэк предлагает путь назад. Радиус: одна страница.
• Ярус виджетов — вокруг независимых рискованных островов: сторонние эмбеды, графики на внешних данных, всё, что рендерит пользовательский контент. Карусель из Hook живёт здесь. Радиус: одна карточка из двадцати.

Антипаттерн — оборачивать каждый компонент «на всякий случай»: десятки одинаковых «упс»-фолбэков дробят страницу на извиняющиеся дыры, и ни для одной никто не проектирует настоящее восстановление. Ярусы заставляют задать правильный вопрос на каждом уровне: что пользователь всё ещё может здесь сделать?

Один продовый нюанс: в разработке оверлей React показывает ошибку, даже когда boundary её поймал, — команды регулярно решают, что их boundary сломан, хотя он работает как задумано. В проде пользователь видит только ваш фолбэк; само сообщение минифицировано до кода ошибки со ссылкой на декодер, а componentStack читается только после применения source maps. React 19 ещё и навёл порядок в логировании: пойманные ошибки логируются один раз через onCaughtError корня вместо дублей в консоли — пайплайновая часть этой истории в уроке 03.