Is there a way to nest routes instead of them all being siblings?

[cha0s]

It seems that the routes are all created as siblings, which means that e.g. using the handle export to automatically generate breadcrumbs will not work since the routes need to be nested for this to work.

In other words if you view the output from autoRoutes(), the route at e.g. /foo/bar is not a bar route in the children key of the foo route.

Am I possibly just missing something? If not, is this fixable?

[kenn]

In the current design, autoRoutes() only creates nested children when there’s an explicit _layout.tsx. Without that, routes that merely share a path prefix like /foo and /foo/bar stay siblings in the generated config. That’s intentional and matches the remix-flat-routes-style behavior.

So for breadcrumbs via handle inheritance, the fix is to introduce a layout route, for example:

routes/
└── foo/
    ├── _layout.tsx
    ├── index.tsx
    └── bar.tsx

That will give you a nested tree where bar is a child of the foo/_layout route.

This is because path-prefix nesting sounds intuitive, but it changes semantics in ways that can be surprising.

The main tradeoff is URL structure vs UI/layout structure. Two routes can share a URL prefix without one being intended to render inside the other. For example, /users/:id and /users/:id/edit often share path segments, but many apps want them as separate sibling screens, not “edit inside detail page.” Default path-based nesting would force an <Outlet /> relationship that authors may not want.

In other words, the current spec is more flexible about file organization because URL hierarchy does not force UI/layout hierarchy.

[cha0s]

Thanks very much for the explanation. That does make sense, and "nested routes" (e.g. rendered with Outlet) are usually awkward, I agree.

It's a little more complicated to generate breadcrumbs than I first thought.

Thank you for your time!