Struct NavController 

pub struct NavController {
    pub push: Box<dyn Fn(&str) -> bool>,
    pub pop: Box<dyn Fn(bool) -> bool>,
    pub current: Box<dyn Fn() -> String>,
    pub enter: Box<dyn Fn(&str) -> bool>,
    pub segments: Box<dyn Fn() -> Vec<String>>,
    pub depth: usize,
    pub layer: Box<dyn Fn() -> u64>,
    pub active: Box<dyn Fn() -> bool>,
}

A mounted host’s control surface. Closures run user code (route builders), so the registry Never holds a borrow across a call (§3.3 discipline: clone the Rc out, then call).

Fields

push: Box<dyn Fn(&str) -> bool>

Push (or, in split/tab presentation, select) a registered route. False = unknown route.

pop: Box<dyn Fn(bool) -> bool>

Pop the top route. already_popped = the native side popped first (iOS back). False = nothing to pop (tabs hosts always return false: they have no stack).

current: Box<dyn Fn() -> String>

Current route path (“” while showing the root).

enter: Box<dyn Fn(&str) -> bool>

Consume one segment of an absolute path. Selectors/tabs accept a declared key (same as push); a nav_stack accepts any segment by pushing it (its destinations are open-ended). Distinct from push so a relative navigate("key") can still fall through a stack.

segments: Box<dyn Fn() -> Vec<String>>

This surface’s contribution to the full route: [] at root, [key] for a nav host / tabs, the whole path for a stack.

depth: usize

How deeply this surface is nested: 0 for one mounted at the window root, 1 for one built inside another surface’s page, and so on.

An absolute path walks outermost-inward, and registration order is not that order: a nav host builds its pages before registering itself, so a stack inside a page registers first. Ordering the descent by depth instead of by position is what lets section/detail find the stack no matter which of the two registered first.

layer: Box<dyn Fn() -> u64>

Presentation order of the containing fullscreen cover; zero for ordinary pages. A cover and its descendants receive Back before navigation underneath it.

active: Box<dyn Fn() -> bool>

Whether this surface is on screen: false for one sitting inside a resident page its host is not currently showing.

A tab bar or a rail keeps every page it has built alive (docs/navigation.md), so the nav surfaces inside the tabs the user is not looking at stay registered. Without this they contribute their segments to current_route just like the visible ones, and the route reads as the concatenation of every tab’s state. Registration cannot answer the question once and for all (which page is showing changes after the build), so it is a predicate.