Give failed screens a useful fallback

An interface failure has a local fallback and error context.

Give failed screens a useful fallback

React error boundaries replace a failed part of the interface with an error state. Wildo connects that fallback to its shared error context and declared frontend actions, so failures can be handled consistently.

Applications can customize the fallback presentation while keeping the common handling path.

Example — Keep navigation around a failed panel

A rendering failure inside a boundary replaces its child panel with a fallback. The rest of the surrounding interface can remain available, and the error follows the same frontend event path as other handled failures.

For engineers

Place the boundary around the failure region

ErrorBoundary catches errors in its descendant React rendering tree. Its default fallback uses the application layout slot; fallback and onError are customization points. The default fallback uses routing context, so mount it within the application’s normal router/provider setup.

This selected source excerpt shows the step after React reports an error:

const wildoError = sharedErrorBuilder.buildReactError(error, errorInfo);

try {
  frontendEventBus.emit(FrontendEvents.ERROR_OCCURED, {
    error: wildoError
  });
} catch (dispatchError) {
  logger.warn('Failed to emit error event:', {dispatchError});
}

if (this.props.onError) {
  try {
    this.props.onError(error, errorInfo);
  } catch (handlerError) {
    logger.warn('Error in custom error handler:', handlerError);
  }
}

The native error and React component information are converted into the shared frontend shape. A failure in reporting is guarded so it does not replace the original rendering failure with another unhandled error.

Separate catching from the user response

Part	Responsibility
Component boundary	Catch descendant render failures and render a fallback
Router boundary	Present route-level failure within the routing surface
Error provider	Keep the builder’s user/organization context current
Global handler	Resolve user wording and execute declared frontend actions
Application slot/preset	Decide the appearance of the fallback

ErrorProvider and the global handler connect errors to notification, navigation and session actions. The message comes through the shared error/i18n path; a custom fallback should preserve meaningful recovery choices rather than exposing a raw stack.

Handle other failures through their own path

A React boundary does not catch arbitrary rejected promises or errors in event handlers. Those must be caught and passed through the application’s error handling path. Resetting a fallback retries rendering; it does not repair corrupt data or guarantee that the next render succeeds.

The frontend logger and event handling provide local diagnostics. Selecting a remote browser-monitoring provider is a separate integration; this boundary alone does not send an incident to Sentry.

Give failed screens a useful fallback