Типизация ErrorBoundary в React 19: асинхронные ошибки, error.cause и production-логиро...
Типизация ErrorBoundary в React 19: асинхронные ошибки, error.cause и production-логирование ErrorBoundary долго был слабым звеном — он не ловил ошибки из промисов, useEffect или setTimeout. React 19 не меняет классовый подход, но появление error.cause и правильная типизация через instanceof делают обработку асинхронных ошибок предсказуемой и безопасной. Почему any в state — ошибка Состояние границы должно быть строго типизировано: Error | null. В getDerivedStateFromError проверяй cause через instanceof Error, не через truthy check. Это исключает мусор из продакшена, где cause может быть строкой, числом или undefined. Production-кейс с fetch При HTTP 500 выбрасывай: throw new Error('HTTP error', { cause: res.status }) В границе проверяй: if (error.cause instanceof Error) { // Логируем полный стек } else if (typeof error.cause === 'number') { // Игнорируем, если статус < 500 } Это позволяет не слать в Sentry временные сетевые сбои. Типизация cause и instanceof Используй instanceof для разграничения классов ошибок — HTTPError, NetworkError, ValidationError. Так ты контролируешь, что идёт в Sentry, а что — только в консоль. Без этого логгер захлебнётся шумом. Вывод: Типизированный ErrorBoundary с error.cause и instanceof превращает асинхронные ошибки из невидимых багов в управляемые инциденты.