Alternative API: This is an optional alternative to flat route definitions. Both approaches can be used together in the same application.
What are Nested Routes?
Nested routes allow you to define your route structure as a tree rather than a flat object. Child paths are automatically concatenated to parent paths, and metadata automatically inherits from parent to child.
Key Benefits
- Concise - No need to repeat parent path segments
- Readable - Structure mirrors your UI hierarchy
- DRY - Shared metadata defined once in parent
- Automatic Inheritance - Children inherit breadcrumbs, permissions, etc.
Basic Example
Compare flat vs nested route definitions:
Flat Route Definition
Nested Route Definition
Notice how child paths are relative - no need to repeat
/documents!Path Concatenation
Child paths are automatically concatenated to parent paths:
Concatenation Rules
- Child paths are joined with
/ - Leading slashes in child paths are stripped
- Parameters (
:id) work in any position - Catch-all routes (
*) can be used as children
Named Routes
Add name property to routes you want to navigate to programmatically.
Names are optional - only add them when needed.
Guideline: Add
name if you use push(name, params) to navigate to the route. Otherwise, omit it.Automatic Inheritance
When hierarchical mode is enabled, child routes automatically inherit from parents:
- Breadcrumbs - Concatenated (parent + child)
- Permissions - Sequential checks (parent AND child)
- Conditions - Parent conditions run first
- Authorization - Parent callbacks execute before child callbacks
Enabling Hierarchical Mode
Inheritance Example
Combining with Flat Routes
Tree and flat route definitions can coexist seamlessly:
Complex Example
Here's a real-world example with permissions, authorization, and nested routes:
When to Use Nested Routes
✅ Use Nested Routes When
- You have deeply nested route structures (3+ levels)
- Child routes always inherit from parents
- Route structure mirrors UI hierarchy
- You want concise, readable route definitions
✅ Use Flat Routes When
- Routes are mostly shallow (1-2 levels)
- You need fine-grained control over inheritance (opt-out flags)
- Route structure doesn't match visual hierarchy
- You prefer explicit path definitions
Best Practice: Use whichever approach makes your code more readable. You can mix both in the same application!
TypeScript Support
Full TypeScript support with type inference:
See Also
- Hierarchical Routes - Automatic parent-child inheritance
- Named Routes - Refactor-safe navigation
- Permissions - Role-based access control
- Route Configuration - Using wrap() for route setup