Remix Route Modules in React Router

[rossipedia]

In keeping with the trend of cross-polination between React Router and Remix, I propose that the Remix Route Module convention be brought over to React Router as a full-blown feature.

What does it look like?

instead of this:

import Root, { rootLoader } from './routes/root';
import Team, { teamLoader, teamAction } from './routes/team';

createBrowserRouter([
  {
    path: '/',
    element: <Root />,
    loader: rootLoader,
    children: [
      {
        path: 'team',
        element: <Team />,
        loader: teamLoader,
        action: teamAction,
      },
    ],
  },
]);

What if you could do this...

createBrowserRouter([
  {
    path: '/',
    module: () => import('./routes/layout'),
    children: [
      {
        path: 'team',
        module: () => import('./routes/team'),
      },
    ],
  },
]);

// in ./routes/layout
export function loader({request}) {
  ...
}
export default function Layout() { ... }

// in ./routes/team
export function loader({request}) {
  ...
}

export function action({request}) {
  ...
}

export default function TeamPage() { ... }

... and have React Router call any loader or action export you had defined in that module, and also wrap your default export in React.lazy() for you?

What problem does it solve?

A couple

• Import bloat - Any decently large application is going to have a lot of routes, which leads to a huge chunk of imports at the top of the route module. Sure you can mitigate this with code folding, but it doesn't help with things like viewing the routes on Github, etc. (for example: Docker Hub currently has 240+ React.lazy() imports in one of the route definition files, and it's nowhere near the largest RR app I've encountered).

• Fewer names - You wouldn't have to do things like: import Team, { loader as teamLoader } from '...'; or even import Team, { teamLoader } from '...';, and it also keeps the loader/action firmly with the code that invokes them, and leaves the route definition module to care about one thing: Your route structure.

• Code splitting - React Router isn't in the business of code splitting, but virtually every bundler knows to split at the dynamic import() call and will do the Right Thing.

• Lazy loading - With this pattern, an engineer wouldn't have to figure out how to lazy load the component's loader or action handler. That lazy loading would essentially come for free, as React Router would dynamically import the module when navigating to that route. The code to render the route, as well as the loader/action, gets imported Just-In-Time.

How would it work?

I imagine the implementation would look something like:

let Component = React.lazy(props.module);

let routeObject = {
  path: props.path,
  loader: (args) => props.module().then((m) => m.loader?.(args)),
  action: (args) => props.module().then((m) => m.action?.(args)),
  element: <Component />,
};

What do you think? In my opinion, this would drastically cut down on the amount of boilerplate necessary for configuring routes in most cases, while still allowing for fine-grained control without changing any existing features.

(It would also have the added benefit of making it super easy to transition from a full client-side RR6 app to Remix!)

[rossipedia]

So it turns out this can be fairly easily implemented in user space, using the same approach as createRoutesFromElements.

Screen.Recording.2023-01-06.at.12.33.10.AM.mov

Although, I think it would be super useful to have a utility like this provided by default from React Router itself. Due to the lazy loading of loader action and errorElement, each module route basically provides all of those props and they have to determine their behavior at runtime. Which isn't too bad, but it does make it so the default errorElement does nothing but throw useRouteError(); which adds some noise to the call stacks.

[brophdawg11]

Slick! As @ryanflorence mentioned in Discord, I always envisioned that someone would put together a webpack/vite plugin for this type of thing and it would live outside of RR. But I do like this idea of a utility that can do this using standard import() without growin the current RouteObject API and without coupling to a given build tool. I'm not opposed to it living in RR as long as it tree-shakes out for folks not using it.

[rossipedia]

Nice! I'll put together a PR and see if it's something worth merging (and also maybe get some help working out some of the less elegant bits). At the very least it can live as a separate lib/util.

[sergiodxa]

I wonder something, if the loader is imported together with the component (same module), wouldn’t that mean the data can’t be fetched until the component loads?

[brophdawg11]

Yeah I think this is the price you pay to have them in one file while using import directly (and not doing any weird compile time stuff) - the payload of the component blocks the start of the data fetch. I played around with what the loads would look like a while back if you had your loader and component in separate files to avoid this. but still wanted to benefit from loading the JS chunks in parallel and it gets a bit tricky but it felt doable. Ruben wrote up a nice article on current state approaches for code splitting - the last section is the gist I was fooling with: https://www.infoxicator.com/en/react-router-6-4-code-splitting

[rossipedia]

Yeah there's a tradeoff there. Do you bundle all your loaders/actions with your route definitions? That could potentially lead to a rather large chunk for the user to download even if they only end up invoking a small portion of that code. But then you end up with a small waterfall where you download the loader JIT and then invoke it, which most likely results in more network requests.

In my mind it's not too terrible of a trade off, but I think this can be designed flexibly enough where for certain critical routes you can just include the loader property directly on the route object and eagerly import it from a second file instead of dynamically imported route module.

As is the Remix Way™... levers :)

[jamiebuilds]

I think this would be an interesting opportunity to experiment with some improvements to Remix's route conventions. I described a few ideas to the team last year https://gist.github.com/jamiebuilds/028f00ee258708d6fdf5419436c9baa9

[sergiodxa]

Those are now implemented as flat routes and it's merged in Remix's dev branch remix-run/remix#4880

[brophdawg11]

yeah - Remix does 2 separate things here:

1. How do I generate a route tree from files on disk?
2. How do I generate route loader/action/element/errorElement from a given file on disk?

The gist (and flat routes) tackle (1) but this is about (2) since RR (at the moment) doesn't know anything about where the files are on disk. You still solve (1) manually and this proposal lets RR do (2) automatically (once you provide the given route file).

[wmdmark]

@brophdawg11 do you have any public code for a proof-of-concept version of what you're describing (sorry if I'm missing where you've already references it)? I was working on something similar myself and would love to see how you are approaching it.

[brophdawg11]

@rossipedia has a POC of this proposal (what I'm referring to as part 2 here) in #9830.

[rossipedia]

Proof of Concept implementation here: #9830

[brophdawg11]

Hey folks! This is released in react-router-dom@6.9.0-pre.0 if anyone is keeping an eye on this and wants to give it a test spin 😉 . You can take a look at the changelog in the release branch for usage: https://github.com/remix-run/react-router/blob/release-next/packages/react-router-dom/CHANGELOG.md. Let us know if you run into any issues!

[skratchdot]

Hey! I was just reading the 6.9.0 release docs and see the new lazy implementation. Thanks for working on this, and adding this behavior!

Something I started using in my code (before I knew about this proposal) is a lazyBuilder function (that I will share below). The one functional difference (besides the syntax), is that it also returns a "preloader" that you can optionally use for nested routes.

So, lazy-builder.tsx:

import { PreloadableComponent, lazyWithPreload } from 'react-lazy-with-preload';

import { RouteObject } from 'react-router-dom';

type SpreadableLazyElement = { element: RouteObject['element'] };
type SpreadableLazyFunction = (
  ...args: Parameters<typeof lazyWithPreload>
) => SpreadableLazyElement;
type PreloadableRouteElement = React.ComponentType<RouteObject['element']>;
type PreloadableAndLazy = PreloadableComponent<PreloadableRouteElement>;
type PreloadableComponentArray = Array<PreloadableAndLazy>;
type PreloadAllComponentsFunction = () => Promise<PreloadableRouteElement[]>;

const lazyBuilder = (): [
  SpreadableLazyFunction,
  PreloadAllComponentsFunction
] => {
  const elements: PreloadableComponentArray = [];
  const lazy = (
    ...args: Parameters<typeof lazyWithPreload>
  ): SpreadableLazyElement => {
    const LazyComponent = lazyWithPreload(...args);
    elements.push(LazyComponent);
    return {
      element: <LazyComponent />,
    };
  };
  const preload: PreloadAllComponentsFunction = () =>
    Promise.all(elements.map((e) => e.preload()));
  return [lazy, preload];
};

export default lazyBuilder;

So instead of:

import HelloPage from './hello-page';
const appRoutes: RouteObject[] = [{
  path: 'hello',
  element: <HelloPage />
}];

you can do:

import lazyBuilder from './lazy-builder';
const [lazy] = lazyBuilder();
const appRoutes: RouteObject[] = [{
  path: 'hello',
  ...lazy(() => import('./hello-page')),
}];

The one neat thing is, you can preload children routes in certain scenarios:

import lazyBuilder from './lazy-builder';
const [lazy] = lazyBuilder();
const [lazyTwo, preloadTwo] = lazyBuilder();

and you can define all your lazy routes with ...lazy(), but you can also define some other routes with ...lazyTwo() (which works just like the other lazy). But anytime you call preloadTwo()- then any routes defined with ...lazyTwo() will be preloaded.

So I will sometimes preload routes in parent loader:

    loader: async () => {
      preloadTwo();
      return {};
    },

example from some code i'm working on:

[brophdawg11]

I'm going to close this out since this was implemented in 6.9.0. Check out the Blog Post or the Release Notes for more info!