Refactor Error Handling with Granular Error Boundaries

[SvenVw]

Summary

Currently, any unhandled error in the application, whether from a page loader or a small component, triggers the root error boundary. This replaces the entire UI with a full-screen error page. This behavior is disruptive to the user experience, as it prevents them from interacting with other, still-functional parts of the application, such as the main navigation or sidebar.

This issue proposes a refactor of our error handling strategy to adopt a more granular approach using nested error boundaries.

Proposed Solution

We will implement local ErrorBoundary components within our nested routes. This will allow us to handle errors at a component or section level, maintaining the overall application layout and interactivity.

1. Localized Error Boundaries for Loaders & Components

• Problem: A failing loader for a single component (e.g., fetching data for a specific field) shouldn't crash the whole page.
• Solution: For routes that represent distinct UI sections (e.g., a card, a details panel), we will export a route-specific ErrorBoundary. This boundary will render a localized error message (e.g., "Could not load this component") directly in place of the component itself, leaving the rest of the page intact.

2. A Distinct 404 "Not Found" Page

• Problem: The page for a 404 (Not Found) error is currently indistinguishable from a generic server error.
• Solution: We will create a dedicated 404 page with a unique design and user-friendly message. This will likely involve creating a "splat" route (app/routes/$.tsx) that catches all unmatched URLs and renders this custom 404 component.

3. Graceful Handling for Action Errors (Toasts)

• Problem: Errors that occur during data submission (actions) should not result in a full error page.
• Solution: We will standardize the use of toast notifications for action-related errors. The existing remix-toast and sonner setup is perfect for this. Action functions should catch their errors and return a toast message, rather than throwing an error that would trigger an error boundary.

4. Consistent "Copy Error" Button for Reporting

• Problem: When a user encounters an error, they should always have an easy way to copy the technical details to report to us.
• Solution: The new InlineErrorBoundary component will include a "Copy Details" button, consistent with the functionality already present in the main ErrorBlock. This ensures users can easily report errors, whether they are full-page or inline.

Action Plan

• Create a reusable InlineErrorBoundary component: This component will serve as a standardized, minimal UI for displaying errors within a component's bounds, and it must include a "Copy Details" button.
• Identify key routes and apply local boundaries: Audit the route structure and add the InlineErrorBoundary to routes that fetch data or contain complex logic.
• Implement a custom 404 splat route: Create app/routes/$.tsx to render a user-friendly "Page Not Found" experience.
• Standardize action error handling: Review critical action functions and ensure they use try/catch blocks to return toast notifications on failure.