remix-flat-routes vs @react-router/fs-routes vs config-based routing

[kentcdodds]

I want to hear from users of the Epic Stack.

Do you prefer remix-flat-routes (what we use now), @react-router/fs-routes, or config-based routes?

[jacobparis]

I vote to keep the same convention

I tend to just use regular fs-routes on my stuff (don't care much for folders) but I can do that with remix-flat-routes too, and then I have the lever available if I want it

[kentcdodds]

Personally I really like the remix-flat-routes because it's flexible enough to be used for simple things and scales up to large codebases as well with reasonable and convention based organization.

Here's the problem I have with config-based routing. It makes it so that everybody has a different convention on where to put files, and it also means that any time you want to change a route you also have to change where the file is, or the file system and your route configuration get out of sync.

This just means extra homework, and inevitably it means that you will have a file system and a route configuration that is out of sync and it doesn't follow any convention at all, which just breeds a lot of confusion.

I understand people's arguments in favor of config-based routing talk about the benefits of not having to have weird characters and file names, and I understand that is useful, but for myself, I have learned to get over the weird characters in the file names in favor of having a single source of truth for both convention and configuration of my routes and files.

[diurivj]

I support Kent's ideas.

I even got used to search for my route modules starting with the _ prefix 😅

[nichtsam]

I also vote to keep the same convention—I appreciate the extras remix-flat-routes brings.

Personally, I’m not a fan of config-based routes. The route code has to live somewhere anyway. It probably makes more sense for library development, but I wouldn’t enjoy it for web app development.

[davepack]

I think config is the only way to go for a large app with many teams contributing to many routes and features. First of all, the file based convention is hard to understand and on-board, when you’ve got a mix of senior and junior devs I think you want a convention that is easy to pick up on for juniors and new senior team members alike.

Also the large app (at least the one I work on) likely has a fairly stable set of routes that don’t change frequently and has established conventions around where files go.

I might also be biased because I have not worked enough in the file conventions to really learn them well and I find them difficult to understand. Whereas code is easy for me to read and follow.

That all said I have experienced the pain in a greenfield, smaller app where my routes and file names are changing somewhat regularly of forgetting to update things on the config and having to do that extra step. I guess I prefer that trade-off to having to learn the file conventions.

[nichtsam]

I don’t fully agree with the ‘hard to understand and on-board’ part. I’ve always worked with file conventions, and I think learning config-based routing would take about the same amount of time as it did for me to get used to remix-flat-routes.

[damiensedgwick]

As someone new to the stack I like the flat routes and everything I have learned so far.

[andrecasal]

I vote for keeping remix flat routes. Easy to understand. Easier to handle than others. Scalable.

[Varkoff]

I have been using remix-flat-routes for more than a year, but don't get autocompletion / typesafety from the new href utility introduced in 7.2.

It seems that @AlemTuzlak 's stack https://github.com/forge-42/base-stack benefits from it (and it uses @react-router/fs-routes).

He has also just released a PR that improves i18n routes, that is the perfect use-case for this.

I therefore consider switching over to fs-routes. But that would mean migrating a lot of route files, unless we can customize the conf to be similar to the Epic-stack's remix-flat-routes.

[kentcdodds]

don't get autocompletion / typesafety from the new href utility introduced in 7.2.

What do you mean?

That screenshot is from the Epic Stack which uses remix-flat-routes 🤔

[Varkoff]

Thank you. Just checked, this was the culprit :

I was wondering why the @react-router/remix-config-routes-adapter package was still marked nightly, after months ... Thanks @kentcdodds .

(installed the correct package just now)

[DennisKraaijeveld]

I prefer using remix-flat-routes, but I understand why some might opt for a config-based approach. For teams and larger projects, a central config file can provide a more accessible overview of all routes, making it easier to manage as the project scales. As my own project grows, I’ve started to feel some annoyance with the increasing filename bloat in a flat route structure.

That said, I still stick with flat routes because I’m used to them, and they work well for my workflow. But if the target is a team or a bigger project, a config-based setup might be the better option.

[kentcdodds]

a more accessible overview of all routes

What about npx react-router routes? Here's the output for the Epic Stack

<Routes>
  <Route file="root.tsx">
    <Route path="*" file="routes/$.tsx" />
    <Route path="auth/:provider/callback" file="routes/_auth+/auth.$provider.callback.ts" />
    <Route path="auth/:provider" file="routes/_auth+/auth_.$provider.ts" />
    <Route path="forgot-password" file="routes/_auth+/forgot-password.tsx" />
    <Route path="login" file="routes/_auth+/login.tsx" />
    <Route path="logout" file="routes/_auth+/logout.tsx" />
    <Route path="onboarding" file="routes/_auth+/onboarding.tsx" />
    <Route path="onboarding/:provider" file="routes/_auth+/onboarding_.$provider.tsx" />
    <Route path="reset-password" file="routes/_auth+/reset-password.tsx" />
    <Route path="signup" file="routes/_auth+/signup.tsx" />
    <Route path="verify" file="routes/_auth+/verify.tsx" />
    <Route path="webauthn/authentication" file="routes/_auth+/webauthn+/authentication.ts" />
    <Route path="webauthn/registration" file="routes/_auth+/webauthn+/registration.ts" />
    <Route path="about" file="routes/_marketing+/about.tsx" />
    <Route index file="routes/_marketing+/index.tsx" />
    <Route path="privacy" file="routes/_marketing+/privacy.tsx" />
    <Route path="support" file="routes/_marketing+/support.tsx" />
    <Route path="tailwind-preset" file="routes/_marketing+/tailwind-preset.ts" />
    <Route path="tos" file="routes/_marketing+/tos.tsx" />
    <Route path="robots.txt" file="routes/_seo+/robots[.]txt.ts" />
    <Route path="sitemap.xml" file="routes/_seo+/sitemap[.]xml.ts" />
    <Route path="admin/cache" file="routes/admin+/cache.tsx" />
    <Route path="admin/cache/lru/:cacheKey" file="routes/admin+/cache_.lru.$cacheKey.ts" />
    <Route path="admin/cache/sqlite" file="routes/admin+/cache_.sqlite.tsx">
      <Route path=":cacheKey" file="routes/admin+/cache_.sqlite.$cacheKey.ts" />
    </Route>
    <Route path="me" file="routes/me.tsx" />
    <Route path="resources/download-user-data" file="routes/resources+/download-user-data.tsx" />
    <Route path="resources/healthcheck" file="routes/resources+/healthcheck.tsx" />
    <Route path="resources/images" file="routes/resources+/images.tsx" />
    <Route path="resources/theme-switch" file="routes/resources+/theme-switch.tsx" />
    <Route path="settings/profile" file="routes/settings+/profile.tsx">
      <Route path="change-email" file="routes/settings+/profile.change-email.tsx" />
      <Route path="connections" file="routes/settings+/profile.connections.tsx" />
      <Route index file="routes/settings+/profile.index.tsx" />
      <Route path="passkeys" file="routes/settings+/profile.passkeys.tsx" />
      <Route path="password" file="routes/settings+/profile.password.tsx" />
      <Route path="password/create" file="routes/settings+/profile.password_.create.tsx" />
      <Route path="photo" file="routes/settings+/profile.photo.tsx" />
      <Route path="two-factor" file="routes/settings+/profile.two-factor.tsx">
        <Route path="disable" file="routes/settings+/profile.two-factor.disable.tsx" />
        <Route index file="routes/settings+/profile.two-factor.index.tsx" />
        <Route path="verify" file="routes/settings+/profile.two-factor.verify.tsx" />
      </Route>
    </Route>
    <Route path="users/:username" file="routes/users+/$username.tsx" />
    <Route path="users/:username/notes" file="routes/users+/$username_+/notes.tsx">
      <Route path=":noteId" file="routes/users+/$username_+/notes.$noteId.tsx" />
      <Route path=":noteId/edit" file="routes/users+/$username_+/notes.$noteId_.edit.tsx" />
      <Route index file="routes/users+/$username_+/notes.index.tsx" />
      <Route path="new" file="routes/users+/$username_+/notes.new.tsx" />
    </Route>
    <Route path="users" index file="routes/users+/index.tsx" />
  </Route>
</Routes>

I feel like that's a great overview of the routes, probably even better than the config version of this structure.

The other thing to remember is just because you use remix-flat-routes doesn't mean you can't also use config based routes in combination:

export default [
	...(await remixRoutesOptionAdapter((defineRoutes) => {
		return flatRoutes('routes', defineRoutes, {
			// ...
		})
	})),
	// extra routes that don't map well to flat routes
	route("some/path", "./some/file.tsx"),
] satisfies RouteConfig

[jacobparis]

maybe it'd be good to have one manual route defined this way so people can see it as an example, and then a comment with explaining how to use npx react-router routes to view the generated output?

[DennisKraaijeveld]

Thanks for that npx react-router routes tip. Created a totally unnecessary script which runs that command and creates a markdown file in the root with an overview of all routes, categorized by parent and with links to the file within your IDE.

😂 Find it a bit easier to have a quick overview and explain/showcase to other devs

[stonetwig]

The constant (imo unnecessary) changes on remix / react router has been annoying and has pretty much made me leave the RR ecosystem. Both at work and on my spare time. Even if the future flags are good and makes for an easy upgrade path I still don't understand certain moves, just like the router config. It took me more than one hour to port router changes to RR7 for an app I run and it gave me a worse DX in the end.

So I am for flat routes.

[jacobparis]

Why did you change it then? The whole point of moving to config first approach is so the React Router team doesn't need to have an opinion on how you do your routing

[stonetwig]

Mostly because when I read the docs, it seems like putting all routes in a config file is the future and I don't want to be bitten in the future by going against the framework. Maybe it's fine and will continue to be but my experience of web dev tells me otherwise.

It's just a bit tiring to have to change many fundamental things quite often. I also have a lot of file uploads in one of my remix app, which means I have to port that also to the new way of handling file uploads in RR7. I'm sure it's better, but it seems quite different and means I have to spend a lot of time doing that as well.

I don't want to sound negative as RR is a great framework. It's just that I don't really have time to spend my free time on porting my spare time projects so it's easier to just do stuff with something more stable such as web components and write my own little router.

[sergiodxa]

it seems like putting all routes in a config file is the future

When Remix v1 came with a file convention, people didn't liked it.
When Remix v2 changed the convention, while still allowing apps to keep using v1 convention, people also didn't liked the new convention.

The config file in React Router v7 is there because some people like v1 convention, some like v2 convention, some like Next.js convention, some like other conventions (e.g. remix-flat-routes), and some prefer to do it all with code.

So instead of a convention, the config file lets you do what you want. This doesn't mean you always have to use the config file, you can use to to generate a convention, like how remix-flat-routes or @react-router/fs-routes gives you functions to use in routes.ts that will enable a convention.

So it's not a bad thing to use a convention instead of the config file yourself, at the end it's a matter of preferences, which is why Kent is asking what's the preference of the community.

[stonetwig]

Sure and I responded with my preference. I just added the comment and honestly sometimes it's hard to be up to date about everything. I didn't know that it was going to be optional and believed it to be strongly recommended.

[markgreenwood]

We've done two Remix / RR7 apps now. The first used flat routes, which was fine. But in the second we started with flat routes and then decided to switch to config-based routing. Although the flat routes is fairly easy to follow once you're used to the conventions, it does strongly couple the routing structure to the directory structure. So if we decide to change the routing, it means changes to filenames and directories. If the changes are significant enough, that ripples through quite a bit.

With config-based routing, that's relatively independent and the structure can be reworked and the changes confined only to routes.ts. We can continue to use whatever filenaming / directory structure convention we had and not disrupt things too much.

Don't know about other folks' applications, but we find it's a challenge to nail down the routing / info architecture right out of the gate if we're doing incremental / evolutionary development. Keeping it flexible is more than just a nice-to-have, it's a desirable feature of the way we work.

[markgreenwood]

In short, I like having the option to do either. 🤷🏼‍♂️