React 19.1: Автоматическая обработка ошибок в Suspense

hannadev

Обложка: React 19.1: Автоматическая обработка ошибок в Suspense для стабильных дашбордов с тысячами компонентов

Рано или поздно каждый фронтенд-разработчик сталкивается с одной и той же болью: в приложении есть куча асинхронных запросов, и каждый может упасть в самый неподходящий момент. React 19 finally придумал нормальный способ обработки этого безумия - Suspense и Error Boundaries теперь работают в связке, вместо того чтобы драться друг с другом.

Если у тебя есть дашборд с сотнями компонентов, которые грузят данные параллельно, то без правильной обработки ошибок это просто катастрофа. Blank page вместо интерфейса - вот что получается, когда один запрос падает и никто не ловит исключение. React 19.1 решает эту проблему элегантно, позволяя разделить логику загрузки и обработки ошибок на разные компоненты.

Как раньше было ужасно

До React 19 ты вынужден был таскать состояние вроде isLoading, isError, errorMessage по всему дереву компонентов и делать сто условных проверок. Это просто боль - дублирование кода, логика размазана по разным местам, сложно читать и еще сложнее поддерживать.

Представь компонент, который грузит пользовательский профиль. Ты должен обработать три состояния: идет загрузка, данные пришли успешно, или произошла ошибка. Раньше это выглядело как:

function UserProfile() {
  const [user, setUser] = useState(null);
  const [isLoading, setIsLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    fetch('/api/user')
      .then(r => r.json())
      .then(data => {
        setUser(data);
        setIsLoading(false);
      })
      .catch(err => {
        setError(err);
        setIsLoading(false);
      });
  }, []);

  if (isLoading) return <p>Загружаем...</p>;
  if (error) return <p>Ошибка: {error.message}</p>;
  return <h1>{user.name}</h1>;
}

А теперь представь, что это не один компонент, а их сотни. Весь этот boilerplate начинает занимать больше места, чем полезная логика.

Suspense + Error Boundaries - идеальная пара

В React 19 все стало намного чище. Suspense занимается состоянием загрузки, Error Boundary ловит ошибки. Они работают на разных уровнях абстракции и идеально дополняют друг друга.

Когда компонент выбрасывает промис (да, в React 19 это нормально!), Suspense перехватывает его и показывает fallback UI. Когда что-то падает с ошибкой - Error Boundary ловит это и показывает backup UI. Никакого дублирования, никакого танца со state’ом.

Вот как это выглядит в реальности:

import { Suspense, use } from 'react';
import ErrorBoundary from './ErrorBoundary';

function UserProfile() {
  const user = use(
    fetch('/api/user').then(r => {
      if (!r.ok) throw new Error('Не удалось загрузить профиль');
      return r.json();
    })
  );
  return <h1>{user.name}</h1>;
}

export default function Page() {
  return (
    <ErrorBoundary fallback={<p>Ошибка при загрузке профиля</p>}>
      <Suspense fallback={<p>Загружаем профиль...</p>}>
        <UserProfile />
      </Suspense>
    </ErrorBoundary>
  );
}

Смотри, как просто! Весь бойлерплейт ушел, осталась только суть. Компонент фокусируется на том, что он делает, а инфраструктура обработки состояний находится на уровне выше.

Streaming SSR - суперсила для больших дашбордов

Теперь самое интересное: в React 19 Suspense работает чудесным образом с streaming SSR. Это означает, что сервер не ждет, пока все данные загрузятся, а начинает отправлять HTML в браузер прямо во время рендера.

Процесс выглядит примерно так: сервер стартует рендеринг, наваливается на Suspense boundary с незаконченной загрузкой - и тут же отправляет все, что рендерилось до этого момента плюс fallback UI. Потом, когда данные приходят, React отправляет финальное содержимое для замены fallback’а.

Для дашборда с сотнями компонентов это киллер-фича:

Пользователь видит контент быстрее - не ждет, пока все загрузится на сервере
Bandwidth экономится - отправляешь что-то полезное, пока данные в пути
Perceived performance стреляет в небо - первый paint происходит гораздо раньше
Graceful degradation - если что-то сломалось, пользователь видит часть интерфейса, а не пустой экран

Это работает благодаря тому, что Suspense и Error Boundaries знают про асинхронность и могут работать с ней на уровне стрима, а не ждать синхронного рендера.

Практическая архитектура для сложных интерфейсов

Когда у тебя есть дашборд с десятками компонентов, нужна стратегия. Просто завернуть все в один Suspense - это неправильно, потому что если хотя бы один компонент долго грузит данные, вся страница будет в fallback’е.

Правильный подход - гранулярная обработка ошибок на разных уровнях:

<ErrorBoundary fallback={<PageError />}>
  <Suspense fallback={<PageSkeleton />}>
    <Header />
    
    <section>
      <ErrorBoundary fallback={<CardError />}>
        <Suspense fallback={<CardSkeleton />}>
          <StatsCard />
        </Suspense>
      </ErrorBoundary>
      
      <ErrorBoundary fallback={<CardError />}>
        <Suspense fallback={<CardSkeleton />}>
          <ChartCard />
        </Suspense>
      </ErrorBoundary>
    </section>
  </Suspense>
</ErrorBoundary>

Здесь происходит волшебство: если StatsCard упадет, упадет только она, а ChartCard продолжит работать. Если весь Header не загрузился - покажется fallback на уровне Header’а, остальное будет отрендерено.

Несколько ключевых паттернов, которые работают:

Nested Suspense boundaries - оборачиваешь каждый независимый компонент своим Suspense, чтобы они загружались параллельно
Hierarchical Error Boundaries - один на страницу (ловит критические ошибки), несколько на блоки (ловит локальные падения)
Skeleton vs Placeholder - разные fallback’и для разного контента помогают пользователю понять, что грузится
Segmented loading - вместо одного большого бандла данных, отправляешь их частями

Обработка ошибок в формах и экшенах

С формами и действиями пользователя история другая. Здесь нужно не просто показать fallback, а обработать ошибку грамотно и дать пользователю возможность повторить попытку.

React 19 для этого добавил useFormStatus и useActionState - это хуки, которые отслеживают состояние отправки формы и позволяют обновлять UI в реальном времени.

Можешь создать компонент, который покажет ошибку конкретного поля, а остальная форма будет доступна для редактирования:

import { useActionState } from 'react';

function SubmitButton() {
  const [state, formAction, isPending] = useActionState(
    async (prevState, formData) => {
      try {
        const response = await fetch('/api/submit', {
          method: 'POST',
          body: formData
        });
        if (!response.ok) {
          return { error: 'Не удалось отправить форму' };
        }
        return { success: true };
      } catch (err) {
        return { error: err.message };
      }
    },
    null
  );

  return (
    <form action={formAction}>
      <input name="email" type="email" />
      <button disabled={isPending}>
        {isPending ? 'Отправляем...' : 'Отправить'}
      </button>
      {state?.error && <p style={{color: 'red'}}>{state.error}</p>}
    </form>
  );
}

Здесь React берет на себя управление состоянием отправки - ты просто описываешь, что делать с результатом. Это намного чище, чем самостоятельно таскать isSubmitting и submitError по всему компоненту.

Оптимистичные обновления - когда ты веришь в успех

Есть еще один вариант обработки ошибок, который React 19 делает проще - оптимистичные обновления. Идея: ты сразу показываешь, что данные обновились, а потом проверяешь это на сервере. Если что-то не так, откатываешь назад.

Для этого есть хук useOptimistic, который позволяет временно обновить UI даже если запрос еще в пути:

import { useOptimistic } from 'react';

function TodoItem({ todo, onToggle }) {
  const [optimisticTodo, addOptimistic] = useOptimistic(
    todo,
    (state, newCompleted) => ({
      ...state,
      completed: newCompleted
    })
  );

  async function handleToggle() {
    addOptimistic(!optimisticTodo.completed);
    try {
      await fetch(`/api/todos/${todo.id}`, {
        method: 'PATCH',
        body: JSON.stringify({ completed: !todo.completed })
      });
    } catch (err) {
      // Откатываемся, потому что addOptimistic откатит автоматически
      console.error('Ошибка обновления:', err);
    }
  }

  return (
    <input
      type="checkbox"
      checked={optimisticTodo.completed}
      onChange={handleToggle}
    />
  );
}

Пользователь кликает - чекбокс тут же меняется. Фиксится на сервере - супер, UI уже в нужном состоянии. Ошибка на сервере - React откатит изменение и UI вернется в исходное состояние. Это улучшает perceived performance, потому что интерфейс отзывается мгновенно.

Преимущества оптимистичных обновлений:

Приложение кажется суперыстрым - UI обновляется мгновенно
Пользователь видит результат своего действия сразу, не ждет сервера
Если сервер вернул ошибку, React откатит изменение автоматически
Работает хорошо даже на медленном интернете
Уменьшает когнитивную нагрузку на пользователя

Что стоит помнить при большом масштабе

Когда ты работаешь с дашбордом из тысяч компонентов, нужно помнить о нескольких вещах. Во-первых, каждый Suspense boundary и Error Boundary добавляет overhead - это не просто обертки, это компоненты, которые должны отслеживать состояние.

Во-вторых, fallback UI должен быть быстрым. Если твой skeleton component требует серьезной обработки, это спорит с идеей streaming SSR. Skeleton’ы должны быть максимально простыми - может быть, даже CSS-only.

В-третьих, think about user experience. Если ты покажешь тысячу skeleton’ов одновременно, это не улучшит восприятие - это испугает пользователя. Лучше группировать компоненты и показывать загрузку по секциям.

Так выглядит хорошая стратегия обработки ошибок:

Один глобальный Error Boundary на уровне всего приложения (catch’ит критические ошибки)
Error Boundaries на уровне ключевых секций (страницы, модалки, карточки)
Suspense boundaries для каждого независимого блока данных
useActionState для форм и операций пользователя
useOptimistic для быстрых обновлений

Эта комбинация дает тебе полный контроль над тем, как приложение реагирует на ошибки и асинхронность.

Будущее обработки состояний в React

То, что React 19.1 делает с Suspense и Error Boundaries, это просто начало. Становится ясно, что framework движется в сторону автоматизации управления состоянием - вместо того чтобы разработчик вручную таскал состояние по всему дереву, React берет это на себя.

Это значит, что в будущем ты сможешь писать код, который фокусируется только на бизнес-логике, а вся инфраструктура обработки ошибок, загрузок и состояния будет работать автоматически. А для больших дашбордов с миллионами данных это означает, что они станут стабильнее и быстрее, потому что ошибки не будут приводить к краху всей страницы.