Not sure how to link a markdown field to data

I’m trying to render a panel of markdown using the available data on the page.

Because I can’t work out how to internally create a page that is a single record, I’m using querystrings, etc admin/9aaa9aa9aaa?structure=00000000-0000-0000-0000-000000000000

I can’t work out how to put a markdown block on that page that is the structure id record from the querystring, to do things like <h1>H1 {{ $nRecord.name }} H1</h1>

I can create a sort of markdown block inside a grid block, and I am able to set the scope as below. The markdown works there. But I don’t want a small markdown block inside a grid block - I’m trying to just render a page full of markdown.

Could you describe the issue you’re encountering here in detail?

I’m trying to use NocoBase to create pages that show one specific item from the database.

Right now, I can only do something like this:

/app/building?building=123

But I want a cleaner, easier-to-read address like:

/app/building/123

And for more complex pages:

/app/building/123/level/456

That means: instead of using ?building=123, I want to use nice-looking URL paths that show what I’m looking at.

Right now, NocoBase doesn’t seem to support this. Is there a way to make it work?


:hammer_and_wrench: Technical Details

:round_pushpin: The Problem

I’m trying to build record-specific pages in NocoBase with friendly URLs that reflect the structure of my data.

At the moment, the only way I’ve found to do this is to:

  1. Create a generic page
  2. Add a “Details” block
  3. Use a query string (?building=123) from the URL
  4. Set the data scope manually using that param

Example current page:

/app/building?building=123

But this is less than ideal.


:white_check_mark: What I’m Trying to Achieve

I want to follow best practice for user-facing routing in web apps:

  • Use path segments instead of query parameters
  • Reflect the hierarchy and relationships of the data
  • End up with something like:
/app/building/123
/app/building/123/level/456

This makes the URLs:

  • Cleaner
  • Easier to read and understand
  • Easier to link to and bookmark
  • More consistent with modern frontend app design

:teacher: Terminology Breakdown

Term Meaning
Query strings A way to pass parameters like ?building=123
Path parameters Parameters built into the URL path like /building/123
Friendly URLs Human-readable, logical, and clean URL structures
Hierarchical routing Routing that follows data structure relationships (building → level)
RESTful routing Usually used for APIs — same concept, but for GET /resource/:id etc

Note: While this kind of routing is sometimes called “RESTful-style,” that term is more accurate when you’re talking about API design. For front-end apps, it’s more correct to say:

  • Friendly URLs
  • Semantic URLs
  • Hierarchical or nested routing

Currently, it only supports the ?parameter format. There are no immediate plans to improve this.

Can this be added to the roadmap - it’s a fairly important (at least to us?) feature allowing for a much clearer and easier to understand modality of people interacting with an app - and doesn’t require a heap of hackery with different hidden routes.