Widget Patterns

Before reading every widget page individually, it helps to keep four recurring patterns in mind.

1. Builder first, view! second

Every widget in this section is documented with the builder API first because it is the most explicit representation of the real interface.

In app code, many of them can also be used inside view!:

view! {
  <Input
    value={self.draft.clone()}
    placeholder={"Type a command".to_string()}
    on_change={Message::DraftChanged}
    on_submit={|value| Some(Message::Submit(value))}
  />
}

Use builders when you want exact construction control. Use view! when hierarchy matters more than construction detail.

2. Stateless vs stateful widgets

Some widgets are effectively stateless:

• Text
• Paragraph
• Block
• Gauge

Others have interaction state that matters across rerenders:

• Input
• List
• Tabs
• Table
• ScrollView
• Scrollbar

When you see stateful widgets, pay attention to:

• ListState
• TableState
• ScrollbarState
• local input value and submission flow

3. Runtime continuity matters

Ansiq is a retained-tree runtime. That means a widget page is never only about drawing.

For stateful widgets, the important question is also:

What happens when a subtree is replaced or rerendered?

That is why many widgets expose state explicitly, and why continuity keys matter in larger apps.

4. Compose from small parts

Many higher-level screens are built from a small set of repeatable pieces:

• Shell for header/body/footer
• Pane or Block for framed sections
• List, Tabs, Table for selection
• ScrollView + Scrollbar for long content
• ComposerBar, BottomPane, SessionTranscript for long-running session UIs

That composition style is the main reason the widget pages are grouped by role, not by crate file order.