🗺️ Flat Routes #4482
Replies: 26 comments 94 replies
-
|
@kiliman Has created a package that implements this here: https://github.com/kiliman/remix-flat-routes 🙏🤩 I haven't had a chance to look deeply at it but will soon. @kiliman can you list here any differences/enhancements/gotchas from my original gist to your implementation before we bring this into Remix proper? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, sorting is still an issue when using the flat-files convention. It's not an issue with flat-folders since it doesn't include an extension. Also note that all those characters ( I like the |
Beta Was this translation helpful? Give feedback.
-
|
@ryanflorence I'm finishing up my presentation this weekend, so I'll be able to send the PR early next week. |
Beta Was this translation helpful? Give feedback.
-
|
Yea I think its better to get support for ignoring extension in file sorting from VS Code or other editors rather than use a different delimiter than |
Beta Was this translation helpful? Give feedback.
-
|
People complained about $ in shell, I don't want to imagine what the pipe operator would do there 😅 |
Beta Was this translation helpful? Give feedback.
-
|
Please don't use the pipe operator, it's way harder to type, the underscore looks much better |
Beta Was this translation helpful? Give feedback.
-
|
There's been some discussion about keeping both conventions as official even in v2. Would be curious to hear everybody's thoughts on doing that? I think I'm fine with it, but I'd prefer to just have one convention and continue to let people do whatever they want with |
Beta Was this translation helpful? Give feedback.
-
|
I love the flat folders, and would be happy to have that style of route as the default, but if both can remain and could be set during the initial project setup script, that would be great. |
Beta Was this translation helpful? Give feedback.
-
|
It's already going to be opt-in in v1 behind a future flag and old convention removed in v2. The question is not about smooth migration paths, that's already a given. The question is should we always keep it as a config option in remix.config.js into v2? I'd rather not because I don't like documenting "two ways to do this, pick what you like". Looking to be convinced otherwise 😋 |
Beta Was this translation helpful? Give feedback.
-
|
I'd be happy to have flat folders as the blessed Remix way. |
Beta Was this translation helpful? Give feedback.
-
|
Based on my personal experience, I like the current nested folder structure. For example, if you had the following routes: Where would you put shared resources for P.S. Our dev team is really enjoying the Remix experience, thank you! 🙏 |
Beta Was this translation helpful? Give feedback.
-
|
I think keeping both conventions available is nice for a few reasons. Mainly, it's a breaking change, and we've already teed up a few breaking changes for v2. Even with codemods/examples/etc., breaking changes cause friction. I would much rather keep both conventions at least for now and give us a bit more time to get feedback on flat routes before asking folks to update more than a config flag. |
Beta Was this translation helpful? Give feedback.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
-
|
Curious here, what is the rationale for using a single underscore for pathless routes instead of |
Beta Was this translation helpful? Give feedback.
-
|
I'm not sure. It was just in the spec. It may also be to balance the trailing underscore option to specify a route segment that is not a layout. |
Beta Was this translation helpful? Give feedback.
-
|
Agreed on the breaking of this convention, as we've already adopted single underscore prefix for another purpose. I think it's nice to keep the double underscore as a signal of Remix internal details. |
Beta Was this translation helpful? Give feedback.
-
|
If you want Remix to ignore the
|
Beta Was this translation helpful? Give feedback.
-
|
We did double because people already had single |
Beta Was this translation helpful? Give feedback.
-
|
@kiliman Can you provide an update on your idea of "Hybrid Routes" I'm using your package in my remix app with the I think the idea of hybrid nesting would be very helpful. If I could group routes nested under my pathless layout directory and then by "feature" and have the main parts of those routes flat within it would go a long way to cleaning up the directory names. To be clear - what I'm envisioning is a hybrid of flat-folders where I can optionally next flat-folder routes in a parent directory for organization. The parent directory could be part of the route or a pathless layout |
Beta Was this translation helpful? Give feedback.
-
|
I finally got hybrid routes working. I'm shooting to include it in |
Beta Was this translation helpful? Give feedback.
-
|
Here's an example of what's possible: ❯ tree app/routes-hybrid
app/routes-hybrid
├── _index
│ └── index.tsx
├── _public
│ ├── _layout.tsx
│ ├── about
│ │ └── _route.tsx
│ └── contact[.jpg]
│ └── _route.tsx
├── test.$
│ └── _route.tsx
└── users
├── $userId
│ ├── _route.tsx
│ └── avatar.png
├── $userId_.edit
│ └── _route.tsx
├── _layout.tsx
└── users.css❯ npx remix routes
<Routes>
<Route file="root.tsx">
<Route index file="routes-hybrid/_index/index.tsx" />
<Route file="routes-hybrid/_public/_layout.tsx">
<Route path="about" file="routes-hybrid/_public/about/_route.tsx" />
<Route path="contact.jpg" file="routes-hybrid/_public/contact[.jpg]/_route.tsx" />
</Route>
<Route path="test/*" file="routes-hybrid/test.$/_route.tsx" />
<Route path="users" file="routes-hybrid/users/_layout.tsx">
<Route path="/:userId" file="routes-hybrid/users/$userId/_route.tsx" />
<Route path="/:userId/edit" file="routes-hybrid/users/$userId_.edit/_route.tsx" />
</Route>
</Route>
</Routes> |
Beta Was this translation helpful? Give feedback.
-
|
The flatness of flat-routes wasn't what attracted me to it in the first place. It was the colocation of data. This seems like the right balance. |
Beta Was this translation helpful? Give feedback.
-
|
Yes I concur. Co-location was my main goal. Hybrid folder structure sounds perfect |
Beta Was this translation helpful? Give feedback.
-
|
Remix flat routes with hybrid routes (and many more features) now pushed as v0.5.0 https://github.com/kiliman/remix-flat-routes |
Beta Was this translation helpful? Give feedback.
-
|
Based on discussion on Discord, somebody asked if it was possible to combine folders (via hybrid routes) with flat-file format.
Here's my response:
However, one option is to add a character to the folder name to treat this as the route prefix. Perhaps a This way you can add some folders for grouping, but still use the simpler flat-files convention. |
Beta Was this translation helpful? Give feedback.
-
|
FWIW, I'll be using https://github.com/kiliman/remix-flat-routes going forward unless Remix adopts this |
Beta Was this translation helpful? Give feedback.
-
|
yeah that + is pretty cool |
Beta Was this translation helpful? Give feedback.
-
|
Any appetite from the Remix team to add it as a built-in feature? |
Beta Was this translation helpful? Give feedback.
-
|
Also curious about this/if there's been further discussion? I know the future flag for flat routes is technically not stable, though this does seem worth getting in before v2. I think technically this is a breaking change, but seems like the number of routes it breaks is quite small. |
Beta Was this translation helpful? Give feedback.
-
|
Is still possible to colocate non-route files when using the |
Beta Was this translation helpful? Give feedback.
-
|
Not sure what functionality is currently included or is going to be included by v2, but wanted to pose this question: will this scale? A commenter on a question here mentioned they have an app being migrated to Remix that's going to 1k routes. It sounds a bit painful to have 1000+ files in the same place. I may have just missed or misunderstood something, but wanted to make sure that as apps get larger and get into 50-100+ routes or larger that this convention doesn't break down. |
Beta Was this translation helpful? Give feedback.
-
|
The https://github.com/kiliman/remix-flat-routes |
Beta Was this translation helpful? Give feedback.
-
|
@kiliman looks very interesting, curious to see how much of this ends up getting upstreamed into Remix! |
Beta Was this translation helpful? Give feedback.
-
|
No file convention will scale to 1000+ routes in a way that every organization is happy with. That's why remix.config let's you define your routes however you'd like programatically :) https://remix.run/docs/en/v1/file-conventions/remix-config#routes |
Beta Was this translation helpful? Give feedback.
-
|
Additionally, I've worked in a rails app that had nearly 2000 routes, so I know apps can get large. Regardless of "how many routes" you have, an app that size has thousands of modules anyway and you have to figure out where to put them. With the new flat routes convention, you have a very solid default choice: every route is a folder and all of the modules used exclusively by that route go in that folder. It think that scales as good as any file organization when you have 10,000 modules. |
Beta Was this translation helpful? Give feedback.
-
|
Makes sense! Looking forward to trying this out soon! |
Beta Was this translation helpful? Give feedback.
-
|
Hey ! I just activated the feature on my project with the future flag v2_routeConvention as suggested in the v1.11.0 changelog. It works like a charm ! Except for one bit, the index routes. Could you tell me if I did something wrong please ? Here is my route tree :
And here is the result of <Routes>
<Route file="root.tsx">
<Route file="routes/_anonymous.tsx">
<Route path="login" file="routes/_anonymous.login.tsx" />
<Route path="share/:token" file="routes/_anonymous.share.$token.tsx" />
</Route>
<Route file="routes/_authenticated.tsx">
<Route path="index" file="routes/_authenticated.index.tsx" />
<Route path="trips" file="routes/_authenticated.trips.tsx">
<Route path=":tripKey" file="routes/_authenticated.trips.$tripKey.tsx" />
<Route path="index" file="routes/_authenticated.trips.index.tsx" />
</Route>
</Route>
<Route path="api/locale" file="routes/api.locale.tsx" />
<Route path="dev/null" file="routes/dev.null.ts" />
</Route>
</Routes>The problems are :
|
Beta Was this translation helpful? Give feedback.
-
|
Change your index routes to _index.tsx ( |
Beta Was this translation helpful? Give feedback.
-
|
Awesome that works 🎉 Thank you @kiliman ! |
Beta Was this translation helpful? Give feedback.
-
|
@ryanflorence @kiliman I think I found a typo in the docs. Before making a PR I would like to know if I understood the implementation correctly. For flat folders to work I need to have an This is what is described in the current docs and the corresponding example. It's also a lot nicer to look at and to reason about IMHO. But maybe I'm missing some implication here? |
Beta Was this translation helpful? Give feedback.
-
|
@Lennard, looking into this now, TL;DR - it's currently treating |
Beta Was this translation helpful? Give feedback.
-
|
@mcansh I‘m still not 100 % sure we‘re talking about the same problem. To say it with @ryanflorence words regarding colocation from his gist:
|
Beta Was this translation helpful? Give feedback.
-
|
@lennerd with v2 routing, use I think the issue here is that there's a bug in the implementation, not something wrong with the documentation. Remember, my package |
Beta Was this translation helpful? Give feedback.
-
|
@kiliman I never said the documentation is wrong. 😅 Again: I think there is a bug in the current implementation not implementation the documented behaviour correctly. |
Beta Was this translation helpful? Give feedback.
-
|
I also got this bug with version 1.12.0, is there a fix for it? Got /cc @ryanflorence Update: my issue is fixed in #5228 |
Beta Was this translation helpful? Give feedback.
-
|
Hey folks. Thanks for this improvements. I just implemented the This feeling came out after I rename the files and notice that to see its full name on my editor, I have to increase a lot the side of the navigation:
I understand that giving the ability of having nested route folder kinda defeats the purpose of the |
Beta Was this translation helpful? Give feedback.
-
|
Flats routes are actually easier to understand and work with, only issue is that sometimes you want to group some routes by it's base, for example if you have a shared layout for most of the routes. Currently you are forced to append |
Beta Was this translation helpful? Give feedback.
-
|
I had been using the |
Beta Was this translation helpful? Give feedback.
-
|
Really hoping the documentation for v2 flat-folders improves. Whoever wrote it definitely favors flat-files over flat-folders. The flat-files was clearly written but folders drops off a cliff. lol If it was written better, I would be more confident about moving forward with v2 but the docs leave me asking more questions. |
Beta Was this translation helpful? Give feedback.
-
|
I use v2 with folders and, for me, it's a much better pattern than v1. This way, every route is a folder with an The structured ends up being something like this: |
Beta Was this translation helpful? Give feedback.
-
|
Interesting. Apparently, the flat-folders convention was "fixed" in v1.13.0 to allow folders for organization as well as colocation. That is, prior to v1.13.0, your routes would have had to be like this (where the entire folder name was the route name separated by before v1.13.0 You can still do this in the current versions, but I do agree that folders make it easier to manage. So in addition to colocation, flat-folders let you move the layout file inside the layout folder. That is you can now have: Whereas in Note: the Unfortunately, that doesn't work. |
Beta Was this translation helpful? Give feedback.
-
|
I think there is a finite set of algorithms that is small enough to be considered manageable to have implemented in Remix Core but that would satisfy >90% of cases people are looking for while the remainder could use the escape-hatch to write a custom implementation. What is the best way to get involved in helping with this if possible? |
Beta Was this translation helpful? Give feedback.
-
|
Is it possible to write a migration script that could automatically convert my Remix repo to route conventions v2 (ie move and rename all the files for me)? |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
I also think that V2 is step backwards. I think that all those "clever" rules with underscores and "route" files and so on only overcomplicated something that was already solved in the most simple and comprehensive way, and for what purpose - Colocation?? In my opinion "colocation" is a non-issue. For people that wanted to colocate their files with their routes there was already a good mechanism to do so by using the And for me personally I am against colocating with your routes and prefer to keep my route folder only with route files. Makes it easier to find the files and understand the structure of the app/website. And if you wanted to colocate things as module you could always create a parallel folder called "modules" or whatever and colocate your stuff there without polluting your routes. ps. Flat routes are okay, and mixing folders and flat routes is probably the best. But abominations like "route.tsx" in every folder is just code smell. |
Beta Was this translation helpful? Give feedback.
-
|
In addition to the |
Beta Was this translation helpful? Give feedback.
-
|
I switched my application over to Knowing whether a route has an I started using the local convention of every route folder needs to end with |
Beta Was this translation helpful? Give feedback.
-
|
I absolutely adore the new v2 routing system. Massive step forward IMO |
Beta Was this translation helpful? Give feedback.
-
|
Would be nice to have the v1 style as a native option without needing to install separate packages to get functionality back that was taken away. We have around 250 routes in one of our projects that we just migrated to remix, and having them all in the same directory is pretty clunky, and makes it difficult to see what the nesting hierarchy looks like. |
Beta Was this translation helpful? Give feedback.
-
|
Is there a way to handle two pathless routes in the same position in the new v2 flat routes? I previously had a structure like this: This meant that the URL With v2, this currently returns an error: |
Beta Was this translation helpful? Give feedback.
-
|
I'm not sure if that's a bug in However, <Routes>
<Route file="root.tsx">
<Route path="orgs" file="routes/orgs.tsx">
<Route file="routes/orgs._withSidebar.tsx">
<Route path="hello" file="routes/orgs._withSidebar.hello.tsx" />
</Route>
<Route file="routes/orgs._withoutSidebar.tsx">
<Route path="world" file="routes/orgs._withoutSidebar.world.tsx" />
</Route>
<Route path="example" file="routes/orgs.example.tsx" />
</Route>
<Route index file="routes/_index.tsx" />
</Route>
</Routes>// remix.config.js
/** @type {import('@remix-run/dev').AppConfig} */
const { flatRoutes } = require("remix-flat-routes");
module.exports = {
ignoredRouteFiles: ["**/*"],
// appDirectory: "app",
// assetsBuildDirectory: "public/build",
// serverBuildPath: "build/index.js",
// publicPath: "/build/",
routes: (defineRoutes) =>
flatRoutes("routes", defineRoutes, { enableUniqueIdCheck: false }),
future: {
v2_errorBoundary: true,
v2_meta: true,
v2_normalizeFormMethod: true,
v2_routeConvention: true,
},
}; |
Beta Was this translation helpful? Give feedback.
-
|
I've seen the same problem when testing the new flat routes convention. Given an app with Remix 1.16 that contains routes The idea is that
However, building the app gives the following errors I'm
|
Beta Was this translation helpful? Give feedback.
-
|
No offense, but I think the new Anyway, my package works fine. <Routes>
<Route file="root.tsx">
<Route path="app/:tenant/planning/results" file="routes/app_.$tenant.planning.results.tsx">
<Route path=":result" file="routes/app_.$tenant.planning.results.$result.tsx">
<Route path="resources" file="routes/app_.$tenant.planning.results.$result.resources.tsx" />
<Route path="unallocated" file="routes/app_.$tenant.planning.results.$result.unallocated.tsx" />
<Route index file="routes/app_.$tenant.planning.results.$result._index.tsx" />
</Route>
<Route file="routes/app_.$tenant.planning.results._overview.tsx">
<Route path="add-result" file="routes/app_.$tenant.planning.results._overview.add-result.tsx" />
<Route index file="routes/app_.$tenant.planning.results._overview._index.tsx" />
</Route>
</Route>
</Route>
</Routes> |
Beta Was this translation helpful? Give feedback.
-
|
Late to the party and this ship has unfortunately probably sailed already, but I personally really dislike this new convention. I think it's a huge step backward in terms of organization. Our app currently has 106 routes and it's a relatively new application with relatively few routes. I really struggle to see how this would work well with a large application with thousands of routes. Coming from a Ruby on Rails background, large production applications often ended up with hundreds of controllers (each controller usually has a couple of routes), and people came up with solutions like namespacing controllers to create some managability in this. A single folder with hundreds of files/folders is simply not very user friendly. One of the things I like/liked about Remix is that it really elegantly solved this problem, because the folder structure follows the user interface, and so as the UI grows in depth of nesting, so does the folder structure. Since I haven't seen anyone else do so, I thought I'd try and argue against the presented arguments:
This is very simple to achieve with even the most minimal of shell scripting: I grant that a beginner might not know this, but since the remix CLI already has a Personally I've never felt the need to see a list of all of my routes, but YMMV.
The counter arguments are already presented. When consistently using the
If I have 60 routes which are all nested under a certain route, and I want to change the name of the route they are nested under, renaming 60 files is much harder than renaming a single folder. This for me is the biggest argument against the flat structure. The route names are duplicated across dozens of file names at worst. Maintaining consistency is going to be very cumbersome and tedious. Moving files around is easy and fast, both in the CLI and in a file explorer.
We can already do this today by simply using a file with dots in the filename as is supported in the v1 route convention. There is no need to create folders for nesting, even today. Users can then opt in to the benefits of nesting by moving the file into folders after the migration is complete.
This is the most convincing "pro" argument in my opinion. I like the solution proposed by another user in the thread to have a built in convention for files ignored as routes (basically a default for In our application we have extracted all reusable components into |
Beta Was this translation helpful? Give feedback.
-
|
I'm not sure if you have tried this yet but we had similar issues with the new convention and remix-flat-routes solved most of them. The "hybrid routes" are something in between the old and the new convention. I'd argue that "hybrid routes" should have been the "official" way as they solve most (if not all) of the issues with the old convention (colocation, etc.) but are much more flexible compared to the official flat route conventions. The only thing which I don't really like about this package too much is how index routes are treated: Unless I missed something it seems like you always need to have an additional folder, e.g. Probably and hopefully, we'll officially get hybrid routes at some point in the future without having to rely on some external package. |
Beta Was this translation helpful? Give feedback.
-
|
I discuss this in my repo kiliman/remix-flat-routes#56 |
Beta Was this translation helpful? Give feedback.
-
|
This idea will look shiny in jokes app but it is creating an absolute mess in routes folder of a corporate app. |
Beta Was this translation helpful? Give feedback.
-
|
I think @kiliman nailed flat file+folder hybrid routes with |
Beta Was this translation helpful? Give feedback.
-
|
This is step in the wrong direction, I believe what is there in v1 is much more superior to this flat structure 🤦 |
Beta Was this translation helpful? Give feedback.
-
|
You can use |
Beta Was this translation helpful? Give feedback.
-
|
@sergiodxa surely there's enough folks in this thread pointing out the pros and cons of both v1-only and v2-only to consider some middle ground as the default? v2 convention seems perfect for managing complex routes at the local level (e.g. |
Beta Was this translation helpful? Give feedback.
-
|
You can write a proposal to suggest another convention, I think this is too subjective to every one taste on how to organize files in an app, I personally didn't liked v2 and I was planning to keep using it until I started using folders for my routes. From what I read from the team, they want to have a single and simple convention, and let every team customize it however they want, but you can always propose new ones. |
Beta Was this translation helpful? Give feedback.
-
|
I think v1 is peak routing. I understand the need to organize helper functions/component next to the route files is needed in specific cases/projects, but to solve that a simple I am forced now to use the |
Beta Was this translation helpful? Give feedback.
-
|
You can continue to use Since Personally, I would have liked the Nice thing about Remix is that you can define your own convention by simply overriding the // remix.config.js
const { createRoutesFromFolders } = require("@remix-run/v1-route-convention");
module.exports = {
ignoredRouteFiles: ["**/*"],
routes: (defineRoutes) => {
return createRoutesFromFolders(defineRoutes, {
ignoredFilePatterns: ["**/.*", "**/*.css", "**/_[[:alpha:]]*"],
});
},
}; |
Beta Was this translation helpful? Give feedback.
-
|
I'm from the future and couldn't agree more. sorry, just my rant. now I'll try the v1 route convention. I hope it's way better than this flat route thing. |
Beta Was this translation helpful? Give feedback.
-
|
I'm also from the future and think this was a big mistake. I've spent an hour and a half trying to get a dynamic route to work. I just want to do posts/:id. I've used everything, SolidStart, SvelteKit, Next, Rails, etc. Remix has the hardest possible routing setup I've seen. Good intentions pave the way to hell. |
Beta Was this translation helpful? Give feedback.
-
|
I am not a fan of the flat routes as the default option personally, but if I understand it correctly you should just need to make a |
Beta Was this translation helpful? Give feedback.
-
|
Ya'll I'm just trying to make my website work and after reading the docs and this thread, I don't think I've ever been more confused in my life. |
Beta Was this translation helpful? Give feedback.
-
|
What are you confused about? |
Beta Was this translation helpful? Give feedback.
-
|
Everything? |
Beta Was this translation helpful? Give feedback.
-
|
how safe it to use @remix-run/v1-route-convention ? |
Beta Was this translation helpful? Give feedback.
-
|
Its an official library from the remix team. And the v1 is just a prefix for saying, its the route convention of this version. So, I guess, it does not get better maintained than that? 🤷♂️ |
Beta Was this translation helpful? Give feedback.
-
|
Apart from that: what are your pain points with it? |
Beta Was this translation helpful? Give feedback.
-
|
my pains with V2 is DRY, the fact that i need to repeat the whole route for each nested route. |
Beta Was this translation helpful? Give feedback.
-
yes but i dont think new project are aware of that package so not sure what will be the in the future. |
Beta Was this translation helpful? Give feedback.
-
|
I'd suggest to take a look at kiliman/remix-flat-routes#39 |
Beta Was this translation helpful? Give feedback.
-
|
I started using Remix today. It was so exciting to see the intuitive approach of forms, error boundaries, loaders, etc. But I hit rock bottom when I found out the new v2 file based router patterns. I think v1's was way more extensive and scalable. I don't think I can use v2's pattern on any medium to large scale projects. I'm sorry but I don't think this is the step towards wrong direction. |
Beta Was this translation helpful? Give feedback.
-
|
You can bring your own convention https://remix.run/docs/en/main/file-conventions/vite-config#routes, there are community maintained one like this one https://github.com/kiliman/remix-flat-routes that is really popular and is a mix between v1 and v2, and there's even an official package for the v1 convention https://github.com/remix-run/v1-compat-utils/tree/main/packages/v1-route-convention. |
Beta Was this translation helpful? Give feedback.
-
|
kiliman/remix-flat-routes#39 is what you're looking for |
Beta Was this translation helpful? Give feedback.
and others
-
Flat Routes File System Conventions
Our current route conventions grew organically and then Jamie hit us with some solid ideas as a catalyst for this. We feel like we have a better idea of what folks need out of the convention especially as React Router apps are being migrated to Remix.
Goals
There are several goals with these changes:
Example
As React Router routes:
Individual explanations:
_auth.forgot-password.tsx/forgot-password_auth.tsx_auth.login.tsx/login_auth.tsx_auth.reset-password.tsx/reset-password_auth.tsx_auth.signup.tsx/signup_auth.tsx_auth.tsxroot.tsx_landing.about.tsx/about_landing.tsx_landing.index.tsx/_landing.tsx_landing.tsxroot.tsxapp.calendar.$day.tsx/app/calendar/:dayapp.calendar.tsxapp.calendar.index.tsx/app/calendarapp.calendar.tsxapp.projects.$id.tsx/app/projects/:idapp.projects.tsxapp.projects.tsx/app/projectsapp.tsxapp.tsx/approot.tsxapp_.projects.$id.roadmap.tsx/app/projects/:id/roadmaproot.tsxapp_.projects.$id.roadmap[.pdf].tsx/app/projects/:id/roadmap.pdfConventions
privacy.jsxpages.tos.jsxabout.jsxabout.contact.jsxabout.index.jsxabout_.company.jsx_auth.jsx_auth.login.jsxusers.$userId.jsxdocs.$.jsxdashboard.route.jsxinvestors/[index].jsxJustification
Make it easier to see the routes your app has defined - just pop open "routes/" and they are all right there. Since file systems typically sort 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.
Decrease refactor/redesign friction - while code editors are pretty good at fixing up imports when you move files around, and Remix has the
"~"import alias, it's just generally easier to refactor a code base that doesn't have a bunch of nested folders. Remix will no longer force this.Additionally, when redesigning the user interface, it's simpler to adjust the names of files rather than creating/deleting folders and moving routes around to change the way they nest.
Help apps migrate to Remix - Existing apps typically don't have a nested route folder structure like today's conventions. Moving to Remix is arduous because you have to deal with all of the imports.
Colocation - while the example is exclusively files, they are really just "import paths". So you could make a folder for a route instead and the
indexfile will be imported, allowing all of a route's modules to live along side each other.For example, these routes:
Could be folders holding their own modules inside:
This is a bit more opinionated, but I think it's ultimately what most developers would prefer. Each route becomes its own "mini app" with all of it's dependencies together. With the routeIgnorePatterns option it's completely unclear which files are routes and which aren't.
Migration Path
You can actually just use remix.config.js right now if somebody writes the code:
Beta Was this translation helpful? Give feedback.
All reactions