Рано или поздно каждый фронтенд-разработчик сталкивается с одной и той же болью: в приложении есть куча асинхронных запросов, и каждый может упасть в самый неподходящий момент. 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 берет это на себя.

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