Error Boundaries: The Pattern Every React App Should Use

What you actually need to know

• React error boundaries catch errors in the component tree and render fallbacks.
• Use them around routes, heavy widgets, and third party integrations.
• The App Router in Next.js provides error.tsx per route.
• Log to your error monitoring tool from componentDidCatch.
• Boundaries do not catch async or event handler errors.

The core argument

React error boundaries are one of those built in features that most apps still do not use. The pattern is well documented. The implementation is small. The benefit is that an error in one part of the app does not take down the whole app. The cost of skipping is the white screen that customers report and the team learns about in support tickets.

The pattern is small. A component class with componentDidCatch and getDerivedStateFromError. The component wraps the part of the tree you want to protect. When a child throws during render, the boundary catches the error and renders a fallback. The rest of the page outside the boundary keeps working.

The Next.js App Router has made this even easier. An error.tsx file per route segment acts as an error boundary. The team gets per route protection without writing the boundary manually. The pattern is the default for new App Router projects.

The discipline is to use boundaries at the right granularity. The whole app gets one for catch all protection. Each route gets one so a broken route does not break the layout. Heavy widgets like charts get one because they often fail and the rest of the page should keep working. Third party integrations get one because vendor failures are common.

The other discipline is logging. The boundary catches the error. The team needs to know it happened. Send the error to Sentry or Bugsnag. The error monitoring tool aggregates and surfaces them. The team can prioritize the worst.

Where to place boundaries

How much does this cost

The cost of adding boundaries is hours per surface. The cost of the logging integration is a few hours total. The total cost for a meaningful app is one or two sprints. The savings is the customer experience that does not break when a component fails.

Features the error handling must have

• Error boundaries at multiple granularities.
• Fallback UI that acknowledges the error and offers action.
• Logging to an error monitoring tool.
• Per route boundaries in App Router.
• Try catch around async code and event handlers.
• Telemetry on error boundary trip rate.
• A practice of testing the fallback path.
• A way to recover without full reload.

Expert opinion

Error boundaries are one of the highest leverage React patterns that most apps still skip. The implementation is small. The protection is real. The teams that use them ship apps that survive component failures. The teams that do not use them ship apps that white screen when a chart library throws an unexpected error. The discipline is to use boundaries by default and to fail gracefully at every level.

>

Yashveer Singh, founder of Yashveer Labs

How this played out on a real project

A client SaaS reported that some customers were seeing blank pages after a recent release. The investigation found a third party charting library that crashed under specific data conditions. The crash propagated up and React unmounted the whole tree.

We added error boundaries around every chart. The fallback was a small message and a retry button. The same data condition still caused the chart to fail but the rest of the page kept working. The blank page reports stopped.

We added more boundaries at the route level and around the heavy widgets. The error monitoring tool surfaced several errors that had been silent before. The team fixed the underlying issues. The customer experience improved meaningfully.

For more on the related work, see building forms that customers love and the patterns that make a SaaS feel premium.

Common mistakes teams make

1. No error boundaries.
2. One boundary at the app root only. Too coarse.
3. No logging integration. Errors are invisible.
4. Fallback is a stack trace. Frightens the user.
5. Fallback offers no action. User has to refresh.
6. Boundaries that swallow errors silently.
7. No try catch around async code.
8. Treating React's default error behavior as acceptable.

A two week plan to add boundaries

1. Week one. Add app root boundary. Add per route boundaries. Integrate with error monitoring.
2. Week two. Add boundaries around heavy widgets and third party integrations. Test the fallback paths.

For more on the related work, read the patterns that make a SaaS feel premium and crash reporting and mobile stability a bare minimum setup. On the broader reliability side, designing for failure a backend engineers mental model is the natural next read.