Askr
Fundamentals

Error Boundaries

Use error boundaries with the current published Askr packages.

  • @askrjs/askr0.0.59

How to use error boundaries

Put the boundary around the smallest route or feature that can recover independently and keep the reset action inside its fallback.

  1. Import the published @askrjs/askr entrypoint.
  2. Keep error boundaries configuration next to the component, route, or server composition root that owns it.
  3. Handle pending, unavailable, cancellation, and failure states, then verify the production path.
import { ErrorBoundary } from '@askrjs/askr/components';

<ErrorBoundary fallback={(error, reset) => (
  <ProjectError error={error} onRetry={reset} />
)}>
  <ProjectWorkspace />
</ErrorBoundary>

Failure ownership

`ErrorBoundary`, imported from `@askrjs/askr/components`, is an opt-in wrapper — nothing catches render errors unless you put a boundary around it. Wrap the subtree that's allowed to fail independently of the rest of the page: `<ErrorBoundary fallback={<div>Something went wrong</div>}><FlakyView /></ErrorBoundary>`.

Fallback UI

The `fallback` prop accepts either static content or a function, `(error, reset) => content`, so the fallback can display the actual error or offer a retry action instead of a generic message. `resetKey` lets you tie the boundary's reset to your own state — changing that key clears the caught error and re-renders the children fresh, which is useful when a boundary wraps content keyed by a route param or selected item.

Recovery

The `reset` function passed into a function-form `fallback` clears the boundary's error state and attempts to render the children again, which is how a "Try again" button in the fallback UI is wired up. Because the boundary still tracks `resetKey` internally, either an explicit `reset()` call or a change to `resetKey` from outside can bring the subtree back.

Reporting

`onError`, an optional prop on `ErrorBoundary`, fires with the caught error so you can send it to logging or monitoring without that concern living inside the fallback UI itself. In development the boundary renders a visible fallback and still surfaces the underlying error to the console, so failures aren't silently swallowed while you're debugging.