Back to blog
June 2, 2026
Routes as product structure
Routes as product structure
Nested routes are not only a technical choice. They describe the shape of the product. When the URL, navigation, and page layout agree, the app becomes easier to remember.
Parent routes hold context
The parent route should establish the area: account, projects, billing, or whatever the user is working inside.
- The parent route names the workspace.
- The child route names the task.
- The tab list makes the relationship visible.
Child routes hold specific jobs
Tabs backed by child routes give each view a URL, history behavior, and a clear place in the app.
| Route | Meaning | Component role |
|---|---|---|
| /app/projects | Project list | Index page |
| /app/projects/:id | Project overview | Parent + child index |
| /app/projects/:id/settings | Project settings | Child route |
| /app/projects/:id/statistics | Project statistics | Child route |
<RouteTabs :tabs="tabs" fallback-value="overview" />If a tab is important enough to share, refresh, or revisit, it probably deserves a route.
The payoff
When navigation, layout, and URL structure agree with each other, the app feels simpler than the amount of functionality it contains.
Route design questions
- Does this view need a URL?
- Would browser back/forward feel natural here?
- Can the parent route explain the context without reading the child content?
- Is there a sensible default child route?