Error Boundaries and Deployment

The final chapter of the React for Beginners series covers the two things that separate a demo from a shipped product: surviving failures gracefully and putting the build on the internet. First you will learn what happens when a component throws, how error boundaries contain it, and why one legacy class-component API still matters. Then you will build and deploy the Vite app you started in chapter 2.

What happens when a render throws

An uncaught exception during rendering used to unmount the whole React tree — a blank white page. React still removes the UI above the failure, so without a boundary a single bad component takes down everything. Errors in event handlers do not unmount the tree (they bubble to window like normal JS); render-time, lifecycle and constructor errors do.

What an error boundary is

An error boundary is a component that catches errors in its subtree and renders a fallback instead of disappearing. It must be a class component — React exposes the two lifecycle methods it needs (getDerivedStateFromError and componentDidCatch) only on classes. This is the one place the class syntax from old tutorials still earns its keep; everything else in your app stays hooks-based.

import { Component } from 'react';

class ErrorBoundary extends Component {
  constructor(props) {
    super(props);
    this.state = { hasError: false, message: '' };
  }

  static getDerivedStateFromError(error) {
    return { hasError: true, message: error.message };
  }

  componentDidCatch(error, info) {
    console.error('Boundary caught:', error, info.componentStack);
  }

  render() {
    if (this.state.hasError) {
      return (
        <div className="error-fallback" role="alert">
          <h2>Something went wrong.</h2>
          <p>{this.state.message}</p>
          <button onClick={() => this.setState({ hasError: false })}>
            Try again
          </button>
        </div>
      );
    }
    return this.props.children;
  }
}

Expected output: when a child throws during render, the fallback panel appears with the error message; the rest of the page around the boundary keeps working. Resetting state re-renders the subtree (and may throw again — that is acceptable for a user-facing retry).

Where to place boundaries

Placement is strategy. Wrapping only <App /> contains the crash but replaces the entire page; wrapping each major section keeps navigation and unrelated UI alive:

<AppShell>
  <ErrorBoundary key={location.pathname} fallback={<PageCrashed />}>
    <Routes>…</Routes>
  </ErrorBoundary>
  <Sidebar />
</AppShell>

Expected output: a crash inside one route shows a per-page fallback while the sidebar and header remain usable. A key tied to the route resets the boundary on navigation, and logging on the server (or to an error service) turns the componentDidCatch report into something you can act on.

Errors outside rendering

Boundaries catch render-time failures only. Plan the other paths deliberately: try/catch inside event handlers and effects, rejected-promise handling with catch around every fetch, and a React-level fallback for the rare unhandled rejection. The ErrorBoundary above handles rendering; your data layer handles its own errors — you covered both patterns in chapter 13.

Building for production

Vite turns your source into static files ready for any static host:

npm run build
npm run preview

Expected output:

vite v6.x.x building for production...
✓ 142 modules transformed.
dist/index.html                   0.46 kB │ gzip:  0.30 kB
dist/assets/index-Bx7q2m.css     12.31 kB │ gzip:  3.21 kB
dist/assets/index-Ck1v9p.js     143.08 kB │ gzip: 46.12 kB
✓ built in 1.21s

The dist/ folder is plain HTML, CSS and JavaScript — no Node required to serve it. npm run preview runs the production bundle locally so you can test the real thing before uploading.

Deploying

Any static host works; the workflow is the same everywhere:

1. Push to GitHub — keep your repository as the source of truth.
2. Connect the repo in Netlify, Vercel or Cloudflare Pages; build command npm run build, output directory dist.
3. Add the SPA fallback — every unknown path must serve index.html, or deep links like /posts/42 404 on refresh. Netlify: a _redirects file containing /* /index.html 200; Vercel: {"rewrites": [{"source": "/(.*)", "destination": "/index.html"}]} in vercel.json.
4. Set the base path if not at the domain root — a project served from /my-app/ needs base: '/my-app/' in vite.config.js.
5. Verify — load the site, refresh a deep link, click through navigation, and check the console for 404s on hashed assets.

This fallback is the deployment-side half of routing: the server always returns your shell, and React Router decides which view to show.

Common mistakes

• Expecting boundaries to catch everything — event handlers, timers and promise rejections need ordinary try/catch.
• One boundary at the root only — a single crash blanks the whole app; wrap meaningful sections instead.
• Deploying without the SPA fallback — the home page works, then any refresh or deep link 404s.
• Wrong output directory or base path — blank page with 404s on assets; confirm dist and base match the URL you serve from.
• Serving node_modules or source files — only dist/ goes live; the build has already bundled what the browser needs.

Practice checklist

1. Wrap a deliberately throwing component in ErrorBoundary and verify the fallback renders.
2. Add a per-section boundary and confirm the rest of the page survives a crash.
3. Log a render error with componentDidCatch and read the component stack.
4. Run npm run build and npm run preview; confirm hashed assets load.
5. Deploy to a static host with the SPA fallback, then refresh a deep link to prove it works.

Congratulations — that is the full React for Beginners path, from an empty folder to a live URL. Browse the other tracks at the tutorials index to keep going, starting with JavaScript Best Practices and Next Steps.