Components and view!

Ansiq keeps two ways to organize UI:

• widget builder APIs
• declarative trees through view!

These are complementary, not competing.

Continue the NotesApp

In the previous page, NotesApp was still one flat render function. Now we split it into:

• NotesHeader
• NotesComposer

fn NotesHeader(text: String) -> Element<Message> {
    view! {
        <Paragraph text={text} />
    }
}
 
fn NotesComposer(
    value: Signal<String>,
    submitted: String,
) -> Element<Message> {
    view! {
        <Input
            value={value.get()}
            on_change={{
                let value = value.clone();
                move |next| value.set_if_changed(next)
            }}
            on_submit={|next| Some(Message::Submit(next))}
        />
        <Paragraph text={format!("Last submit: {}", submitted)} />
    }
}
 
fn render(&mut self, cx: &mut ViewCtx<'_, Message>) -> Element<Message> {
    let draft = cx.signal(|| String::new());
 
    view! {
        <NotesHeader text={"Type and press Enter".to_string()} />
        <NotesComposer
            value={draft.clone()}
            submitted={self.submitted.clone()}
        />
    }
}

The point is not only readability. The point is that component boundaries also become runtime scope boundaries.

This also keeps the same state split from the previous page:

• in-progress local input stays in a signal
• durable submitted data stays in app state

So splitting the UI into components does not blur state ownership. It makes it easier to explain.

What view! is best for

Use view! when:

• hierarchy matters more than construction detail
• the UI is structurally deep
• a declarative tree is easier to read than chained builders

What builders are best for

Use builders when:

• you need explicit conditional assembly
• you want full Rust-native construction control
• a macro would obscure important control flow

Why component boundaries matter in Ansiq

In Ansiq, components are not only for reuse. They also define:

• reactive scope boundaries
• subtree replacement boundaries
• continuity boundaries

That means component structure affects runtime behavior directly.

Next

Continue with State, Focus, Input.
The same running example will grow a list and selection state so focus and continuity become concrete.