React Error Boundary Design Patterns

What this prompt does

This prompt makes the AI act as a React reliability engineer and design a layered error-boundary system for a [app_type] application. Instead of a single catch-all boundary, it builds a base ErrorBoundary in [components_directory] that logs to [error_service], then [boundary_count] specialized variants — page, section, widget, and data — each degrading at a different granularity. It adds retry-with-backoff for data failures, a dev-only error dashboard, helper HOCs and hooks, and integration tests.

The structure works because it matches the failure model of real React apps: a crash in one widget shouldn't blank an entire dashboard. By separating boundaries by scope, a failing chart can show a compact indicator while the rest of the page keeps working, and a full-page failure can still render navigation so users aren't stranded. The [max_retries] setting drives exponential backoff in the DataErrorBoundary, so a flaky API gets a chance to recover on its own before the error UI takes over, and the [dev_environment] flag keeps the diagnostic dashboard out of production. Routing logs to [error_service] means every caught error carries its component stack, message, timestamp, and user context, which is what makes the reports actually actionable.

When to use it

• You're shipping a production React app and want graceful degradation instead of blank screens
• A single unguarded render currently risks taking down a whole view or dashboard
• You need different fallback behavior for full pages versus inline widgets
• A data-fetching layer hits flaky APIs that often recover on retry
• You want errors reported to [error_service] with component stacks attached
• You're standardizing error handling across a growing component tree
• You need to catch errors from event handlers and async code that boundaries miss natively

Example output

Expect a set of React components and supporting code: a base ErrorBoundary class with getDerivedStateFromError and componentDidCatch, the [boundary_count] named boundary variants accepting custom fallbacks via render props, the retry-with-backoff logic for DataErrorBoundary, a global error context plus an ErrorDashboard gated behind [dev_environment], a withErrorBoundary HOC, a useErrorHandler hook for imperative throwing, and React Testing Library tests that simulate component errors and assert on the rendered fallbacks. The output is structured as labeled steps so you can drop variants in incrementally rather than rewriting your tree at once.

Pro tips

• Set [error_service] to whatever you actually use; the componentDidCatch logging shape changes between Sentry and other trackers
• Keep [max_retries] low (the default 3 is sensible) — aggressive retries on a truly broken endpoint just delay the error UI
• Remember class boundaries can't catch errors in event handlers or async code, which is exactly why the useErrorHandler hook exists
• Gate the ErrorDashboard strictly behind [dev_environment] so stack traces never reach production users
• Match [components_directory] to your project layout so generated imports resolve cleanly
• Always wire up the integration tests; an error boundary that silently stops catching is worse than none