Currently, NocoBase pages for accessing individual records (like a specific building or level) only support URLs with query strings, such as:
/app/building?building=123
Many users—especially those building user-facing portals—would prefer cleaner, more readable URLs:
/app/building/123
/app/building/123/level/456
Why This Matters
- Cleaner and friendlier URL addresses make sharing, linking, and bookmarking easier.
- URLs that use “path parameters” are more consistent with modern web applications and expected by most users.
- More readable addresses reinforce the structure of your data and application.
Current Situation
Today, it is only possible to:
- Create a page (e.g.
/app/building) - Use query parameters (like
?building=123) to scope the Details block or fetch specific records
Examples of what we get now:
/app/building?building=123/app/building/level?building=123&level=456
Feature Request: Semantic URL Routing
I’m requesting that NocoBase adds support for route-based parameters—so we can configure pages to accept parameters as part of the path, not only as query strings.
What I want to achieve:
- Match routes like
/app/building/:buildingIdand/app/building/:buildingId/level/:levelId - Use these
:buildingIdand:levelIddynamic parameters inside the Details block (or anywhere else) to display the appropriate record
What this would look like:
/app/building/123→ shows Building 123 details/app/building/123/level/456→ shows Level 456, child of Building 123
Benefits
- URLs are easier to read and understand for users
- Able to set Title and other values to provide better context to the user
- More natural navigation and linking between related records
- Enables better integration with external links, QR codes, and navigation for single-page apps
- Brings NocoBase in line with frontend frameworks like Next.js, React Router, etc.
Technical Details & Suggestions
- Allow pages to be created with route templates using parameters (like
/app/building/:buildingId) - When a user visits such a page, NocoBase should pass the path variables (e.g.
buildingId) as available variables/context to Details or Table blocks - Page blocks should be able to use these parameter values directly for querying and scoping
- For deeply nested navigation, each level of routing should pass down the relevant identifiers
Potential Implementation:
- Add a visual page designer option for “route parameters”
- Allow blocks to use those variables, e.g.
{{ params.buildingId }}in the data scope
Terminology (for clarity with team)
| Term | Meaning |
|---|---|
| Query string | The ?key=value part, e.g. ?building=123 |
| Path parameter | The :key variable in path, e.g. /building/123 |
| Semantic URL | A URL that is clean, readable, reflects the resource |
| Nested/Hierarchical | URLs showing data relations, e.g. /building/123/level/456 |