RouterProvider onError

[ryanflorence]

RFC: #9881

RouterProvider catches errors from:

• loaders
• actions
• rendering

and then renders the <RouterProvider errorElement>. This extends React's componentDidCatch capabilities to include errors when loading or mutating data.

The purpose of this behavior to make it incredibly rare, by default, for a user to see a blank page or a spinner looking busy forever when the app has in fact died.

However, it is insufficient for error reporting and logging since the errors are only accessible to the app developer inside of a component's render lifecycle.

On the server, the server entry module has handleError as a good reporting entry point, but there is no equivalent in the browser. This is has been a missing feature in the API.

To fill in this feature gap, <RouterProvider> will no receive an onError prop that will be called whenever an error is thrown from loaders, actions, or components so that app developers can log errors in a single, reliable place.

<RouterProvider onError={(error, info) => {} />

• error whatever was thrown
• info in the case of a render error, this is the React errorInfo argument to componentDidCatch, but in the case of loaders and actions it will be something else (don't know what it looks like yet)
• This will also be called for errors triggered
  • by fetchers calling loaders/actions
  • by streamed UI wrapped in <Await>. The <Await errorElement> is still in charge of the UI, but the error will also go to <RouterProvider onError>
• This prop will also by on <HydratedRouter> since it's a wrapper of <RouterProvider> and most apps will want to have a custom entry.client.tsx to add their error reporting

This should also give folks who have a root error boundary (for reporting) and are migrating to RouterProvider (or routes.ts) to have a centralized place to report errors. React Router errorElements are for the UI, and onError is for reporting. If people still want a root error boundary are bothered by react router catching all render errors in its tree, they can simply have their errorElement rethrow and continue to use their root error boundary.