#3461431: Client-side error handling

Introducing error boundaries on the UI, I'm starting with a generic component that we can re-use across the component tree, and adding it to a few critical places. The styling of the component is not according to an approved design. Neither is the copy for the error messages. All of this is meant to be a starting point that we can continuously improve upon.

The outpout comes with a default heading, which can be overridden. It displays the message from the thrown error object, which can come from React itself while trying to render a component subtree, or we can dispatch an error boundary imperatively e.g. after async code has run. The reset button's text can also be customized, as well as its action. By default it will simply re-render the component tree, but we can e.g. retry API requests, dispatch an undo action to remove a change that caused a failure etc.

Implementation plan

• Generic <ErrorBoundary> component based on react-error-boundary;
• <ErrorCard> and <ErrorPage> components with styled output — used by <ErrorBoundary>;
• Unit testing <ErrorBoundary>;
• Placeholder for logging errors with an API call inside <ErrorBoundary> (implementation is out of scope of this issue);
• Top-level <ErrorBoundary> added in main;
• Place an initial set of error boundaries by evaluating the component tree using a "recursive line of questioning" explained by this blog post:
  • AppRoutes: errorElement for React Router
  • AppRoutes/App
  • AppRoutes/App/Layout and handle API call useGetLayoutByIdQuery, use the same boundary as App
  • AppRoutes/App/Canvas
  • AppRoutes/App/Preview and handle API call usePostPreviewMutation
  • ContextualPanel, add errorElement for async load by React Router
  • ContextualPanel/DummyPropsEditFormRenderer, handle API call useGetDummyPropsFormQuery
  • ContextualPanel/DummyPropsEditForm, handle API call useGetComponentsQuery
• End-to-end test one or more API call failures by mocking requests in Cypress