Components, loops, and i18n

These three features solve different problems. Do not use a compile-time loop where the product needs a live data list, or use a visibility condition where the product needs authorization.

Components are compile-time composition

component name(params...) {} defines a page-level macro. use name(...) supports positional arguments, named arguments, and defaults. If the component has explicit IDs or internal event targets and is used more than once, use ... as namespace prefixes the expansion so each use remains distinct.

Static for is not a data query

page index {
  component card(page, label="Open") {
    button "card-$page" $label primary -> page $page
  }

  view {
    for page in [home, settings] {
      use card($page)
    }
  }
}

for x in [...] {} expands a static array at compile time, with $index, $first, and $last in context. It is not a source-driven or live data list. Use afs-list/repeat for a runtime list whose data path and target behavior are explicitly supported.

include/partial require a runtime include resolver; import brings in component definitions only and does not create page nodes. Include/component expansion has a default depth boundary and reports cycles rather than trying to resolve them indefinitely.

Localize source, not guesswork

After an app declares locales [en, zh], a page can include one i18n {} block:

i18n {
  title { en "Welcome" zh "欢迎" }
}

h1 :title

The shorthand compiles to a translation key. A key can also reference existing source material. Missing inline translations can fall back during rendering, while strict locale checks can report coverage gaps; an unknown i18n key fails. This feature does not automatically translate copy or replace Web Device’s localized content-object system.

For data-driven list semantics, see Events, state, and bindings. Site content objects and their locale files belong to the target's Web Device layer, not to this DSL page.