Что произошло

Автор начинает с типичной ошибки: каждый сетевой вызов оборачивают в блокирующий loading, UI замирает при мутациях, поиск «дёргается» на больших списках. React 19 решает это приоритетами: фреймворк может прерывать, откладывать и возобновлять работу рендера.

Архитектура вводит две «полосы» обновлений:

• Срочные — keystroke, click; коммитятся сразу.
• Переходные — тяжёлая фильтрация, расчёты; уступают срочным.

useTransition возвращает [isPending, startTransition]: обёртка state-update помечает его как несрочное, isPending — для локального индикатора без блокировки страницы. Если пользователь печатает быстрее, чем завершается фильтрация, React отбрасывает устаревший переход и стартует новый — без ручного debounce и отмены запросов.

useOptimistic формализует оптимистичный UI: показываем intended result до ответа сервера, при ошибке React откатывает. Для чатов и форм это снимает ручную синхронизацию rollback.

Suspense в React 19 координирует несколько async-границ: прогрессивные fallback вместо одного спиннера на всю страницу, один финальный commit без мигания.

Почему это важно

Пользователь ощущает отзывчивость в миллисекундах. Поиск по 5–10k строк, который лагает на каждый символ, «ломает» доверие к продукту. Concurrent-модель переносит сложность приоритетов в фреймворк — меньше boolean isLoading и цепочек setState в обработчиках.

Миграция пошаговая: профилировать React DevTools, обернуть дорогие updates в startTransition, добавить границы Suspense вокруг независимых async-секций. Автор указывает на 40–60% снижение блокирующего времени на тяжёлых UI при умеренном росте памяти на tracking переходов.

На практике

1. Поиск/фильтры — setQuery синхронно, фильтр внутри startTransition; isPending для dim/spinner.
2. Формы и чат — useOptimistic + server action в transition; rollback при ошибке автоматически.
3. Данные — вложенные Suspense по независимым секциям, не один boundary на весь layout.
4. Порог — transition имеет смысл для операций >100 ms; мгновенные updates только добавят overhead.

Итог

React 19 concurrent — не «ещё один hook», а смена модели: приоритет взаимодействия пользователя над фоновой работой. Начать стоит с поиска и тяжёлых списков — там выигрыш виден сразу, без переписывания всего приложения.