A view is a component: a node in the UI tree with its own layout, behaviour, and styles. This chapter covers how views are declared, wired to logic, composed, and reused.Coming to view.tree cold: From TypeScript to view.tree builds one component twice, once as a hand-written class and once as a tree, and shows the code the tree compiles to. Read it first if the syntax below feels like a new language rather than shorthand.
A component $my_card lives in my/card/ and is described by up to three files, each with a clear job:card.view.tree — what the component is: its structure and default bindings.card.view.ts — how it behaves: TypeScript methods, reactive state.card.view.css.ts — how it looks: typed styles checked by the compiler.Keeping structure, behaviour, and style apart is deliberate — each file stays small and readable, and the layout is never tangled with logic.None of the three is mandatory on its own. Drop card.view.tree and write the class directly in namespace $: the structure becomes ordinary methods and the component still works. The rest of this chapter uses the tree, because that is what the structure looks like once the plumbing is generated for you.
view.tree describes structure declaratively. Indentation is nesting; there are no closing tags.1$my_card$mol_view2 sub /3<= Title $mol_view4 sub /<= title \5<= Body $mol_view6 sub /<= text \Every capitalized name (Title, Body) becomes a real property you can reach, override, or style. Every lowercase binding (title, text) becomes a value you can compute in .view.ts.
Two operators connect a property to its source:<=one-way: the child reads a value from the owner.<=>two-way: the value flows both directions — used for inputs.1$my_form$mol_view2 sub /3<= Field $mol_string4 value?<=> text?\Here the input's value and the owner's text stay in sync automatically: type in the field and text updates; set text in code and the field reflects it.
