Ergonomics of usage with lazy loading per route and error boundaries

[gnapse]

Take this minimal app with lazy-loading per route:

import { lazy } from 'react'
import { BrowserRouter, Routes, Route } from 'react-router-dom'

const Home = lazy(() => import('./home'))
const Search = lazy(() => import('./search'))

function App() {
  return (
    <BrowserRouter>
      <Suspense fallback={<div>Loading…</div>}>
        <Routes>
          <Route path="" element={<ErrorBoundary><Home /></ErrorBoundary>}/>
          <Route path="search" element={<ErrorBoundary><Search /></ErrorBoundary>}/>
        </Routes>
      </Suspense>
    </BrowserRouter>
  )
}

The ErrorBoundary component is a class-based error boundary, keeping some boolean flag state that's turned on when there was an error. This includes lazy-loading errors (i.e. the chunk fetch failed).

The problem is that the way reconciliation works, the error boundary will be shared across all sibling routes inside a certain parent Routes. So the inner state of this ever-lasting error boundary is not reset when you switch to other views.

My first instinct, trying to be clever, was to put a single error boundary around it all, and have it use the useLocation().key as its key prop. That way, you'd get a new error boundary every time you switch views. However, this soon proves being an issue. This makes your app re-mount views that should not be unmounted and mounted again. For instance, a mere change in the query params of a view re-mounts the entire view. Switching to the useLocation().pathname instead of the key might improve that particular scenario, but it still re-mounts on pathname changes that are not really switching to another view.

So the only remaining alternative I see is manually applying a key per error boundary:

        <Routes>
          <Route path="" element={<ErrorBoundary key="home"><Home /></ErrorBoundary>}/>
          <Route path="search" element={<ErrorBoundary key="search"><Search /></ErrorBoundary>}/>
        </Routes>

This, however, becomes repetitive and verbose pretty soon. Not to mention error-prone. So the next step would be to make a helper to reuse this pattern.

You'd think you could make a MyAppRoute sort of component wrapping the Route component, but that's a no-go. The Routes component requires that its children must be exclusively Route elements (ref). So your only choice is to move away from jsx and create a helper function that is not meant to be called as a React component, but directly instead:

function route({ path, element, key /* optional, we fallback to use the path as key */ }) {
  return (
    <Route
      path={path}
      element={<ErrorBoundary key={key ?? path}>{element}</ErrorBoundary>}
    />
  )
}

Which you would use like this:

        <Routes>
          {route({ path: '', element: <Home />, key: 'home' })}
          {route({ path: 'search', element: <Search /> })}
        </Routes>

Much better for this simpler example. But it still can become inconvenient or unidiomatic when your Route elements also require children.

So the question is: is this the only way? Or am I missing something and there's a better way to make this work while keeping the ergonomics and the idiomatic use of React and JSX more intact than the direction on which I'm going?

[nicoqh]

Here's an attempt at an error boundary whose key only changes after an error has occurred (i.e. not on every URL change):

https://gist.github.com/donaldpipowitch/1248ca4658506c7c8b481edfbd740ca7