Remix Flat Routes – An Evolution in Routing
From Author:
This talk introduces the new Flat Routes convention that will most likely be the default in a future version of Remix. It simplifies the existing convention as well as gives you new capabilities.
This talk has been presented at Remix Conf Europe 2022, check out the latest edition of this React Conference.
FAQ
To migrate an existing app to use Remix FlatRoutes, you can use the included migration tool by running the command 'mpx migrate-flat-routes' and specifying the source and target folders. This tool helps reorganize the routes into the new flat file or flat folder structure.
Yes, Remix FlatRoutes can handle route configurations from multiple directories. You can specify an array of paths to the routes folder in the Remix config, and FlatRoutes will automatically merge them into a single namespace, simplifying the management of routes across different backends or sections.
In Remix FlatRoutes, a single underscore prefix is used for pathless layouts, and a dot is used instead of a slash to separate URL segments. To specify that a segment is not a layout, an underscore suffix is used, indicating the absence of an outlet.
In the Flat Folders convention of Remix, each route's folder acts as a namespace where supporting files like CSS, components, and images can be co-located. This allows for relative imports within the route file, simplifying the development and maintenance of the application.
Unlike the typical nested folder structure in Remix, FlatRoutes uses a flat file system where all routes are defined in filenames using dots to separate URL segments. This approach decreases the complexity of the file system and makes the routes easier to manage and refactor.
The main benefits include better visibility of route structures, co-location of support files such as CSS and components with routes, reduced friction during refactoring and redesign, and easier migration from other frameworks.
Remix FlatRoutes is a new routing convention introduced to simplify the file structure in the Remix framework by eliminating nested folders and allowing easier refactoring and redesign. It was initially introduced as a separate NPM package and is expected to be integrated into future versions of Remix.
Video Transcription
1. Introduction to Remix Flat Routes
Hi, I'm Michael Porter. I'll be speaking at RemixConf Europe on Remix Flat Routes and Evolution in Routing. I'll start with a brief introduction to the current routing convention. Remix uses folders to determine the parent layout, while Next.js requires a folder for every segment of the route. Next.js also uses separate files for named exports, leading to a large number of files. However, Next.js allows co-locating supporting files in the route folder.
Hi, I'm Michael Porter. You may know me online as Killamon, which is short for Killamonjaro. I've been a big fan of volcanoes for a long time. I'm excited to be speaking to you today at RemixConf Europe. My presentation will be on Remix Flat Routes and Evolution in Routing.
First, I'll start by giving a brief introduction on the current routing convention as we know it today. Here is a typical routing structure. It consists of a pathless layout for public pages, like the about page, a user section with its own layout which has a list view, a user detail view, as well as an edit page. Remix uses folders to determine the parent layout. It is expected that the parent layout will include an outlet to render its children. In this example, there is no user ID folder because we want the edit page to use the same user's layout as the other routes. Since the edit page is not nested, we use the dot for flat layout instead of the nested layout. When you create a nested layout, Remix requires you to create a folder for its children, plus a file for the layout itself. Unfortunately, one of the drawbacks of this convention is that the folder in a layout file ends up separated in your editor, since folders are typically displayed first. This can be annoying, especially on large applications with many routes.
As you know, Next.js recently introduced their own take on nested layouts. Let's compare their convention with Remix. Here is the same routing structure as the previous example. Next.js uses parentheses for pathless layouts, similar to Remix's double underscore prefix. The one thing you'll notice is that Next.js requires a folder for every segment of the route. The leaf route is a file named page. If a route segment adds a layout, you create a layout file. With Next., layouts and pages are separate things, whereas Remix doesn't differentiate. Again, looking back at our user edit route, Next.js looks for the closest layout, which is user slash layout. Another major difference with Remix is that Remix uses named exports for things like meta, links, headers, error boundary, etcetera. And Next.js uses separate files for each. This can result in a large number of files, depending on your app's needs. It led one person on Twitter to tweet this screenshot. Granted, this is an extreme example. One of the benefits of a folder for each route, though, is that Next.js does let you co-locate supporting files in the route folder.
2. Introduction to Remix FlatRoutes
Remix FlatRoutes is a new convention that aims to make it easier to see and organize the routes in your app. It allows for the co-location of support files with routes, decreases refactor and redesign friction, and helps apps migrate to Remix. FlatRoutes were first introduced by Brian Florence and have since been implemented as a separate package. To add it to your app, simply npm install dash d RemixFlatRoutes.
Things like CSS, components, images, etcetera. This is one of the main things Remix devs have been asking for. We'll discuss how Remix FlatRoutes supports this shortly.
Now that we have that out of the way, let's discuss the new Remix FlatRoutes convention. It's currently a separate MPM package, but will be included in a future version of Remix as core functionality.
So what are the goals of the Remix FlatRoutes? Make it easier to see the route your app is designed. Just pop open the Routes folder, and they're all right there. Since the file system typically sorts folders first, when you have dozens of routes, it's hard to see which folders have layouts and which don't today. Now all related routes are sorted together. Allow co-location of support files with routes. You'll see how you can keep your styles, components, and other supporting files with your routes. Decrease refactor and redesign friction. While code editors are pretty good at fixing up imports when you move files around, and Remix does have the tilde import alias, it's just generally easier to refactor code base that doesn't have a bunch of nested folders. Remix will no longer require this. Additionally, when redesigning the user interface, it's simpler to adjust the names of the files rather than creating and deleting folders and moving routes around to change the way they nest. And finally, help apps migrate to Remix. Existing apps typically don't have a nested routes folder structure like today's conventions. Moving to Remix is arduous because you have to deal with all of the imports. Also, as we saw with Next's new nested layouts, FlatRoutes make it easier to migrate from other frameworks to Remix.
So Remix FlatRoutes was first introduced as a gist by Brian Florence back on April 7th of this year. He posted the link on the Remix board, and I just happened to see it. And I was intrigued because I, too, was looking to simplify my routing structure. Less than two weeks later, I made the first commit implementing the FlatRoutes spec. The trickiest part was trying to figure out how to determine the parent layout when there were no folders. Simply a dot separated file name. We'll discuss how that was implemented in a little while. An interesting point is that it wasn't until a month later that Next.js posted the first layouts RFC, describing their new nested layouts convention, which is now available as an experimental feature in Next.js 13. As I mentioned before, Remix FlatRoutes is currently implemented as a separate package. To add it to your app, simply npm install dash d RemixFlatRoutes. Since routes are determined at build time, this is a dev dependency and is not needed at run time.
Comments