builtIns.tree demo

• Authoring with tree`…`: lit-like markup that produces [tag, pattern, children] element specifications. Literal attributes become ' :=' attributes (class="card crew"), ${…} values are paths (src=${'?.small'} reads vm.patch.small), .dateTime= sets a property, and an element's only ${…} is its textContent. Keys markup can't express (the ' ?=' ternaries) are spread in as a pattern object: <span ${{ '_ ?=': [...] }}>.
• microJoin: text mixed with values (${'?.parseDate?.longUtc'} UTC, T+${'?.time'}s: ${'?.reason'}) becomes a microJoin: each value in its own element (<span>, or <data value> for numbers), the literal text around it.
• Pipes: named functions used as path segments. The date is '?.parseDate?.longUtc' with parseDate: Date.parse and longUtc a preconfigured Intl.DateTimeFormat's format; core summaries are a pipe too.
• Itemscope managers as view models: { tag: 'section', ish: 'rocket-manager' } attaches RocketManager to the rocket card (by registered name, so the config stays JSON; no itemscope attribute). The card's patterns read its getters ('?.heightLabel'). "Toggle units" sets rocket.ish.metric, whose setter calls ctx.rebind(): the card updates without a tree rerun, and the setting survives "Run again".
• Events: the "Increase by one" button binds its own click with @click=${{ call: 'increaseHeightByOne' }}, i.e. ' +=': { on: 'click', call: 'increaseHeightByOne' }. Its host is the subtree's from — the card's RocketManager — so no host lookup or attribute is needed; the method calls ctx.rebind(). Tree gives the binding a default dedup key, so reruns replace the listener rather than adding another.
• Async onAssigned: LinksManager marks the links "verifying…", awaits a simulated check, then "✓ verified". Tree binds right away and rebinds by itself when the promise settles.
• Static children: the rocket card's heading and its three spec rows, all resolving against the card's manager.
• Rebinding in place: every button re-runs the same tree with a new view model. The log reports how many of the previous elements were reused; only "Clear & rebuild" creates new ones.
• Null values: keepNullish keeps the details paragraph when details is null, and a '??' ternary chain shows the placeholder.
• $parent: the status badge hangs off the success key and reads its sibling upcoming from the enclosing view model, via ' ?=' ternaries (['$parent?.upcoming', 'Upcoming', ['?.', 'Success', 'Failure']]).
• Native arrays: <ul ${each(of, { key, empty })}> makes the element a repeat (['ul', pattern, { each, key, empty, of }]), with its single child as the item. each is stamped once per item (inside it, ?. is the item and $parent the array's holder), key reuses items' elements across reruns, empty replaces the items when there are none (failures), and of points at the array (of: '?.linkList' repeats over the links manager's getter). Lists are rendered synchronously with the rest of the tree.
• Switches: ${choose('?.phase', { scheduled: tree`…`, hold: tree`…`, … }, fallback)} produces { switch, cases, default }, which renders the case the data picks, on every render. The Mission status card has six phases with genuinely different markup (a countdown, a hold reason, live altitude and speed, spec rows, a failure list…), and a fallback for a status with no case. "Next phase" steps through a simulated status feed: a new phase replaces only the card. "Tick" changes values within the phase: the same card is rebound in place. Compare the status badge, whose ' ?=' ternaries can only switch its text. In the Flight timeline, the switch is each's item, so every event (a milestone, an anomaly, or anything else, via the fallback) gets its own markup.

By design:

• Managers don't render DOM: structure stays in the tree config.
• No microdata (itemscope/itemprop), by design.