Skip to main content

ARC 2.0.0-beta.25

Events, navigation, and visibility

Use current DSL sugar for clicks, named-page navigation, and local updates while keeping visible version-bounded.

The DSL -> is not a universal arrow. The current parser treats it as button/action click shorthand; other nodes need an explicit on <event> -> .... First decide whether you need an in-page update, AUP page navigation, an AFS action, or browser URL navigation.

Current action shapes

aup
button open "Open" primary -> page details
button load "Load" primary -> set viewer src "/items/42"
button bump "Bump" primary -> set dial state {value: 7, dirty: true}
action -> exec "/.auth/logout"
action -> navigate "/.well-known/service/login"

Their boundaries are:

DSL formCompiled intent
-> page detailsset.page on _root, switching to a named AUP page
-> set <id> src ...Update the target node's data path
-> set <id> state ...Update the target node's UI-local state
-> exec ...Call an AFS action
-> navigate ...Client-side browser-level URL navigation

The old JSON page: "details" is a deprecated shortcut. New DSL should use -> page details, so generated output uses the current _root + set.page form.

When one update must set src, props, or multiple state fields together, use complete events={...}. One-line sugar does not cover every compound update. Make the event object explicit rather than combining competing click handlers for one logical action.

Visibility is not yet one fully typed cross-device promise

The current DSL compiler accepts and emits a visible condition field, and Showcase DSL uses it. At the same time, the base AUPNode TypeScript interface does not list visible as a universal field. This documentation therefore treats it as a conditional field supported by the DSL/runtime at this target version, not a guarantee that every renderer has identical visibility semantics.

When using it:

  1. Keep the core tree understandable without the visibility condition.
  2. Accept both true and false conditions in the real target renderer.
  3. Do not use hidden UI as authorization. A hidden control must not be the only barrier to an unauthorized AFS action.

For the full event/state/caller-scope boundary, read Events, state, and bindings and Caller identity and safety.