Slim can also be authored from explicit runtime JSON.
In this mode, your code builds the same program shape that the Xuda runtime already consumes. This is useful when another system owns the UI tree or when the page should be generated deterministically.
Why teams choose JSON authoring
- code generators can emit the runtime tree directly
- the output is deterministic and machine-friendly
- HTML is not required as the authoring surface
- you can compose programs from data structures in JavaScript
Core idea
Instead of writing:
<div xu-store="{'count':0}">
<button xu-click="{'@count': @count + 1}">Increment</button>
</div>
you build the node tree explicitly:
{
_id: "demo",
properties: { menuType: "component", menuTitle: "Demo" },
progFields: [],
progEvents: [],
progDataSource: {},
progUi: [
{
id: "root",
type: "element",
tagName: "xu-single-view",
attributes: {},
children: [
{
id: "button_1",
type: "element",
tagName: "button",
attributes: {
"xu-content": "Increment",
"xu-click": "{'@count': @count + 1}"
},
children: []
}
]
}
]
}
When JSON authoring is a better fit
Use it when:
- a builder or code tool generates the program
- you want exact control over node ids and structure
- you are teaching the runtime shape itself
- you want to compare HTML and runtime-tree authoring directly
Relationship to Xuda CLI
Xuda CLI ultimately compiles its friendly source files into the same kind of runtime document model.
That means Slim JSON mode is a good way to understand what the CLI compiler emits behind the scenes.