Index routes

[kiliman]

From @mrksbnch remix-run/remix#4482 (reply in thread)

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. routes/something/_index/index.ts, because something like routes/something/_index.ts is treated as a regular route file.

[kiliman]

With remix-flat-routes, a route is determined by its full name. There are two modes: flat-files and flat-folders.

With flat-files, the route is the filename that ends with *.tsx. It treats it as flat-folders if it ends with */route.tsx. Notice how the last segment includes the /.

These are equivalent:

a.b.c.tsx        (flat-file)
a.b.c/route.tsx  (flat-folder)

Index routes are simply any routes that end with _index.

These are equivalent:

a.b.c._index.tsx        (flat-file)
a.b.c._index/route.tsx  (flat-folder)

NOTE: I'm using route.tsx here, but technically any of the following is considered a route in the flat-folders convention. Everything else is treated as a colocated file.

• index.tsx
• route.tsx
• layout.tsx
• page.tsx
• *.route.tsx

Also, any file starting with _ is treated as a route module.

1. Useful to move your routes to the top of the folder when you have many colocated files
2. You can name the file anything you want, so you don't have a bunch of route.tsx files.
3. One exception is if the file ends with *.server.tsx. It will not be treated as a route.

a.b.c/_about.tsx => /a/b/c   (_about is not a route name, just the filename)
a.b.c/child.route.tsx => /a/b/c/child  (here child is a route)
a.b.c/_route.tsx => /a/b/c
a.b.c/_route.server.tsx (not a route)

I really need to rewrite the README.

[kiliman]

Again, you don't need _index/index.tsx. Just name it _index.tsx. You can have both flat-files and flat-folders in your routes.

You only need the folder if you want to colocate files.

_index/
  _home.tsx
  component.tsx
  image.png
  styles.css

Technically, remix-flat-routes also supports just naming it index.tsx, or index/route.tsx. But I think it's kind of ambiguous, since it can mean the default module as well as an index route, so I recommend sticking with _index. With Remix v2 routing, it must be named _index.

[kiliman]

but probably some other convention could be used to create nested index routes.

I'm not exactly sure what you mean here about "nested" index routes. In Remix, an index route cannot have any child routes, so there will never be a time when you have something like:

a.b._index.c.d._index

Index routes are always leaf routes.

[mrksbnch]

Hm, I need to test this later. My comment was specifically about "nested" index routes (hybrid routes). So, "routes/nested/_index.tsx" is a normal route and not an index route. With your explanation, this makes complete sense (thanks again) but it wasn't intuitive for me the first time I encountered this. To get around this, I need to create a "/routes/nested/_index/index.ts" file.

[kiliman]

Yes, because, as I said, the _index part has to be part of the name. If you're using flat-folders, then _index has to be part of the folder name.

Internally, it converts routes/nested/_index/index.tsx to routes/nested._index.tsx

1. Replace .../route.tsx to .tsx
2. Replace +/_layout.tsx to .tsx (special rule for hybrid flat-files, so you can have the layout inside your folder instead of outside it, like v1 routes)
3. Replace +/ to .
4. Replace / to .

Now everything looks like a flat-file route.

a/b/c/route.tsx => a/b/c.tsx => a.b.c.tsx

a.b.c+/_layout.tsx => a.b.c.tsx
a+/b+/c.tsx => a.b.c.tsx

[mrksbnch]

Thanks and sorry that my explanation wasn't very clear (with "nested" I was referring to flat-folders). It's also not an issue, just something that was a little confusing at first.

I assumed (when I started with this package) that "routes/nested/_index.tsx" would be identical to "routes/nested/_index/index.tsx", i.e. both are treated as an index route (without children). Again, I might well be the only one with this intuition.

I then (after reading through the examples) noticed that this package treats everything beginning with an underscore (in a folder) as a regular route. Your explanation gave the detailed explanation as well.

[kenn]

I think @kiliman nailed it with v0.5.1 convention. This feels the most intuitive, hybrid solution that deserves the default behavior to me. (only wishing with/without "+" would be reversed)

❯ tree app/routes-hybrid-files/
app/routes-hybrid-files/
├── _auth+
│   ├── forgot-password.tsx
│   └── login.tsx
├── _public+
│   ├── _layout.tsx
│   ├── about.tsx
│   ├── contact[.jpg].tsx
│   └── index.tsx
├── project
│   ├── _layout.tsx
│   ├── parent.child
│   │   └── index.tsx
│   └── parent.child.grandchild
│       ├── index.tsx
│       └── styles.css
└── users+
    ├── $userId.tsx
    ├── $userId_.edit.tsx
    ├── _layout.tsx
    └── index.tsx

[kiliman]

Thanks. I agree about wishing the + was reserved for colocation, but unfortunately, the original flat-routes spec already used the /. I added the +/ convention to allow folders for organizing flat-files.

I'm thinking of creating a remix-hybrid-routes package that isn't tied to the original spec.

[kenn]

On second look, I'm wondering if we still need $userId_.edit.tsx (the trailing _ to escape from current layout) in this manner.

Concretely, index.tsx renders a collection (a table of records, etc.) and $userId renders an individual item. These views are usually very different anyway. So the parent-level layout tends to be generic / thin and only contains a navigation component.

In other words, index.tsx is uniquely different from the rest of subpaths — all the subpaths with $postId falls under the same sub-navigation (e.g. tabs), so the layout tend to be set at the $postId level.

In my use case, I have something similar to this (I'm still using v2 flat-file, but conceptually).

app/routes/
├── _auth
│   ├── forgot-password.tsx
│   └── login.tsx
├── _public
│   ├── _layout.tsx
│   ├── about.tsx
│   └── index.tsx
└── dashboard
    ├── posts.index.tsx
    ├── posts.$postId._layout.tsx
    ├── posts.$postId.tsx
    ├── posts.$postId.edit.tsx
    ├── posts.$postId.edit_history.tsx
    ├── posts.$postId.comments.tsx
    ├── bookmarks.index.tsx
    ├── bookmarks.$bookmarkId._layout.tsx
    ├── bookmarks.$bookmarkId.tsx
    ├── bookmarks.$bookmarkId.edit.tsx
    ...
    ├── _layout.tsx
    └── index.tsx

dashboard._layout contains the top-level navbar (vertical sidebar that contains "posts", "bookmarks", etc.) and dashboard.posts.index is rendered inside the layout. posts.$postId._layout defines the sub-level navigation (horizontal tabs) and the tab contains "post details" , "edit history" and "comments". "edit" is also rendered in the same layout with the "post details" look. I think this would be pretty common (You don't want to render "edit" without the sub-level navigation)

Again, having _layout stand out in the tree looks great to me. 👍

[mbrowne]

I'm a big fan of the "Nested folders with flat-files convention", but one thing I don't like as much is that it allows both index.tsx and _index.tsx to mean the same thing. It's not just a matter of consistency; treating index.tsx as a route also makes it more likely that developers will unintentionally add new routes when they create subfolders for helper functions/partials/etc, if they add an index.ts or index.tsx (barrel file) in the subfolder. My solution to this, which seems to work well so far, is to simply add the following rule to ignoredRouteFiles:

                return flatRoutes('routes', defineRoutes, {
                    ignoredRouteFiles: [
                        // Override the default flat-routes convention so that *only* files
                        // beginning with an underscore can be index routes. This ensures
                        // consistency and prevents us from unintentionally creating routes
                        // when adding an index.ts(x) file in a non-route subfolder.
                        '**/index.{tsx,ts}',
                ...