Module tree 

The mounted UI as the runner sees it — and the seam that lets the app’s own runtime own it.

An app’s widgets, signals, layout nodes and overlays all live in thread-locals. In a normal build there is one copy of each and it does not matter who mounts the tree. Under hot reload the app is a dylib with its own copies: a tree mounted on the host’s side registers its segment effects in the host’s reactive runtime while view() reads the dylib’s signals, so no subscription is ever established and nothing re-renders on its own (the historical bump_force_ticks workaround, which only fires on input events — so an animation, a background thread’s result or a timer stays invisible until the user moves the mouse).

So mounting is the app’s job: App::mount hands the runner a UiTree it drives through this trait, and a dylib-backed app mounts a HotTree inside itself. Same shape the plugin subsystem already uses for embedded UIs (crate::plugin::PluginInstance).

Structs

HotTree

A tree that lives on the app’s side of a hot-reload boundary: the dylib mounts it (so its segment effects are created in the dylib’s reactive runtime, subscribed to the dylib’s signals) and the host drives it through the shims the app! macro exports. Held by the host only as an opaque pointer — every method below runs inside the dylib.

LocalTree

A tree mounted in this process, on top of a ComponentList.

TreeView

Adapts a UiTree to the devtools inspector’s view of a tree.

Enums

Frame

One composed frame: borrowed straight from the segment cache when the tree is in this process, owned when it had to be copied out of a dylib.

Traits

UiTree

The mounted UI the runner drives: event dispatch, composition, and the dirtiness/generation gates it uses to decide whether a frame is worth rendering.