Make Routes component participate in data loading

[MrHus]

What is the new or updated feature that you are suggesting?

Make the <Routes> component participate in data loading.

Why should this feature be included?

Currently I'm using the <Routes /> component as a way to split up my routes in multiple different files.
This way my routes do not grow very large, and I keep things manageable.

Currently I'm looking at the new "loader" feature and how to integrate it in my application. But the loaders
do not work for nested <Routes />. The documentation says:

"If you're using a data router like createBrowserRouter it is uncommon to use this component as it does not participate in data loading."

It would be nice to support <Routes /> in combination with the "createBrowserRouter" as to not get a GOD routing
file containing all routes of a large application.

The only way forward I see now using the current API is not using "createRoutesFromElements" and importing
"arrays" and merge them at the top, but this way I loose the "routes as jsx" features.

[maxprilutskiy]

I second this.

Unless I'm missing something, to use the new loader feature, createBrowserRouter suggests defining all the routes upfront and using that together with <Outlet />s.

However, if you think about it, it just undermines code-splitting techniques. Using routes-at-the-root solution would require either reference route components directly, which would disable code-splitting, or lazy loading routes as well as all of their child routes to make it work. For example, it would be simply impossible to make /users and /posts load lazily, while /user/:userId and /post/:postId in a regular way together with their respective parent routes.

When a component is required to know about not only its direct children, but also about children of its children, it just breaks incapsulation and becomes an unlikely scalable solution.

I understand react-router team might push the community towards using createBrowserRouter and routes-at-the-root approach to make it easier then to switch to remix in the future. And that could be really nice to have this option some day. But if this API breaks such a crucial thing as defined by the user code splitting, it just simply would not work.

Alternatively, what I thought of is that we could just start nesting prefixed RouterProviders throughout the app, to avoid defining all the routes at the root of the app; but I haven't tested this hypothesis, and it doesn't sound quite right.

[brophdawg11]

Following up on this - Route.lazy introduced in 6.9.0 adds first-class code-splitting at the route level. We're still not quite at full micro-frontend style architecture where entire sections of the route tree can be lazily discovered, but it's something we're thinking about. Whatever we land on though will continue to keep routing and data fetching decoupled from rendering (explained in a bit more detail in my comment below)

[brophdawg11]

The only way forward I see now using the current API is not using "createRoutesFromElements" and importing
"arrays" and merge them at the top, but this way I loose the "routes as jsx" features.

@MrHus createRoutesFromElements simply transforms the JSX to the array notation - so there shouldn't be any reason you couldn't leverage that to import your sub-arrays (written in JSX) and merge them at the top?

@maxprilutskiy We will likely eventually add some "recommended" code splitting approaches to the docs, but you have various options available in the current setup. Another community member did a great write-up of some options here: https://dev.to/infoxicator/data-routers-code-splitting-23no.

As for making <Routes> participate in data loading, I don't think we've ruled it out completely, but it goes a bit against the ideas behind 6.4 - which is to decouple data fetching from rendering. Fetching inside the render lifecycle (i.e., when rendering descendant <Routes>) re-introduces the same waterfalls/spinners we're hoping the 6.4 APIs eliminate! Ryan gave a good talk on this at Reactathon: https://www.youtube.com/watch?v=95B8mnhzoCM.

Here's the main challenge with getting descendant Routes to participate in data-loading, as I see it:

1. Assume your app defines <Route path="/users/*" loader={userLoader} element={<UsersApp/>}> in which UsersApp has descendant <Routes>
2. Your user clicks <Link to="/users/1">
3. At this point, all the router knows about is the /users/* route, so we go into a navigation.state="loading" state and run the singular loader we know about ahead of the render pass.
4. Loading finishes and we update state.location="/users/1" and navigation.state="idle" and hand off to the render cycle.
5. Uh-oh! During render we just found more routes with loaders - so we can't actually render since we've not yet got all of our data!
   1. What do we render? We don't have data so anything calling useLoaderData() inside your descendant Routes is going to break :/. So you need to now do data-checking inside your components and this breaks the happy-path guarantee of useLoaderData, and it becomes the same DX as if we were just fetching in components in 6.3 and before.
   2. Do we throw back out to a higher level suspense boundary? That breaks the current UI you were on prior to clicking the link though :/
   3. Do we go back into navigation.state=loading? That re-triggers the global loading indicators that were just removed because loading finished :/

So the idea of allowing descendant Routes (unknown to the router prior to render time) is a bit at odds with some of the major design goals of 6.4 (decouple fetching and rendering, reducing spinners, etc.)

We do agree that it's currently non-optimal for large apps to have to specify all of their routes up-front, and we have ideas in mind to alleviate that by adding some form of runtime route discovery, but I don't think that discovery will necessarily happen in the react render lifecycle - more likely it will happen through some other API we can tap into prior to rendering.

I'm going to leave this open for now but I suspect this will get converted into a Discussion in which we can continue to figure out the right API for the type of route discovery

[gaspardip]

So I wrote this on the remix discord a while ago but I'll leave it here so it doesn't get lost.

The current solution makes too many assumptions about the application and takes too much control away from users in my opinion.

Kind of related to what @maxprilutskiy said, I think a good solution would be being able to declare multiple "sub" routers, then have a "root" router that composes all of them, very similar to what express.Router does, where you are able to declare a router for an entire route tree and apply middlewares and whatnot to it.

Why this is good:

• It allows me to be as granular as I want with my route definitions (giving users back some control about where they want their routes to live in) + allows me to keep route encapsulation
• It allows for more natural code-splitting (the current workaround I was pointed to feels like a hack to me)
• It still decouples data-fetching from rendering (spirit of 6.4) and does so outside the react's render cycle (vs runtime discovering/registering)
• Compatible with current requirement for data-loading (declaring all routes at the top level). You could still technically declare all of them in one go, but in case you want to be more granular, you'd be able to.

Granted, the "root" router wouldn't be able statically determine the entire route tree but that doesn't matter because each "sub-router" would know the routes it cares about and the data they need to fetch in order to be rendered.

Here's a very rough usage as I imagine it:

// users/routes.tsx
import { UserLayout } from './UserLayout';
import { NewUser } from './NewUser';
import { UserDetails } from './UserDetails';
import { UsersList } from './UsersList';
import { EditUser } from './EditUser';

const usersRouter = createBrowserRouter([
  {
    path: '/',
    element: <UsersLayout />,
    children: [
      { index: true, element: <UsersList /> },
      { path: 'new', element: <NewUser /> },
      {
        path: ':userId/*',
        loader: ({ params }) =>
          fetch(`/api/users/${params.userId}`).then((res) => res.json()),
        children: [
          { index: true, element: <UserDetails /> },
          {
            path: 'edit',
            element: <EditUser />,
          },
        ],
      },
    ],
  },
]);

export default usersRouter;

// main.tsx
// lazy-load usersRouter, users-related components are not included in the initial bundle
const usersRouter = () => import('./users/routes.tsx')

const rootRouter = createBrowserRouter([
  {
    path: '/',
    element: <Layout />,
    loader: () => fetch(`/api/config`).then((res) => res.json()),
    children: [
      { index: true, element: <Home /> },
      // `router` should be able to accept lazy-loaded routers
      // `router` and `element` are mutually exclusive
      { path: 'users/*', router: usersRouter }, 
    ],
  },
  {
    path: '/login'',
    element: <Login />,
  }
]);

[mz8i]

Exactly! We really need a mechanism like the ones present in so many server technologies (Express, FastAPI etc) to register sub-routers

[brophdawg11]

I think the concept of "sub routers" is misleading. A router (in the browser at least) is a data-aware abstraction around the current browser location (window.location/window.history) - of which there is only one. So there can only be one "router" in that sense of the word.

The concept of separated and lazily-loaded route sub-trees is more of how I think about this and I'm working on a proposal around this at the moment. I'll cross-link to here once it's ready.

[tlmader]

We have an application that uses lazy-loaded descendant routes. I am running into this scenario when attempting to take advantage of the new useMatches hook for breadcrumbs.

[jaryway]

Yep, useMatches can't get the Route's handle data.

[brophdawg11]

I'm going to convert this to a discussion so it can go through our new Open Development process. Please upvote the new Proposal if you'd like to see this considered!

[mgmarlow]

Very much in favor of this feature to support chunking/lazy-loading bundles of components, rather than per-component.

Regardless of the feature, it would be great to clean up some of the error messages that happen in violation of the intended data API use. For example:

• Use of useLoaderData() throws useLoaderData can only be used on routes that contain a unique "id", even when the loader is defined directly on the route.
• Add an id to that route and now useLoaderData() returns undefined.

It's a little unclear in the usage of useLoaderData/useRouteLoaderData that a configuration defined via useRoutes or Routes is completely incompatible with the data APIs.

[brophdawg11]

We should probably spread this information around a bit more (PR's welcome!) but right now we try to list all the "Data APIs" that require a data router here: https://reactrouter.com/en/main/routers/picking-a-router#data-apis

We have a specific callout on the doc about the lack of Data API usage - that could probably be copied over to useRoutes as well.

[yay]

Please note that errors also don't bubble up with React Router 6.4+ if the <Routes> element is used.
Here is a sandbox for the app from the official tutorial modified to use the <Routes> element that highlights the issue:
https://codesandbox.io/s/gifted-goodall-ky4qhu?file=/src/index.tsx

If you click the Throw error button on the root route, it works as expected and shows the ErrorPage page errorElement.

However, if you click the Throw error button on the child route, the stock DefaultErrorElement that comes with RR is shown.

[mgmarlow]

Yep, you have to add an errorElement to each of your sub-route boundaries as well as your root. I assume the error doesn't bubble up to the root because errorElement requires a data router and assumes the route tree is static.

Here's how I have it set up for my app:

const appRoutes  = [
  {
    id: "apps",
    path: "",
    errorElement: <GenericErrorBoundary />,
    children: [ ... ]
  }
];

const AppRoutes = () => {
  const element = useRoutes(appRoutes);
  return <>{element}</>;
};

const rootRoutes = [
  {
    id: "root",
    path: "/",
    errorElement: <GenericErrorBoundary />,
    children: [
      { path: "apps/*", element: <AppRoutes /> },
    ]
  }
]

createBrowserRouter(rootRoutes)

Note that I provide an errorElement at each Routes boundary since they don't automatically bubble up.

[jaryway]

routes-at-the-root cannot dynamically register routes based on permissions

[brophdawg11]

👋 Hey folks, we just published a new Route Discovery RFC that I think should address the concerns in this proposal - please let us know over there if you have comments!

[brophdawg11]

Closing this discussion as it should be handled via https://reactrouter.com/en/main/routers/create-browser-router#optsunstable_patchroutesonnavigation