Module layout 

The application skeleton — AppLayout.

AppLayout is the only shape an engine consumes. It is a plain data structure with public fields plus a builder-style API. Every slot is a Node of the same generic type — when rendered with snora, that binds to iced::Element<'a, Message>, so all four layout slots accept any iced element regardless of how the application organized its view code.

Filling slots

AppLayout::new(body) is the minimum — just a body element. Every other slot has a sensible default and is set via a chainable method:

let layout = AppLayout::new(my_body())
    .header(my_header())
    .side_bar(my_sidebar())
    .footer(my_footer())
    .direction(LayoutDirection::Rtl)
    .on_close_menus(Message::CloseMenus)
    .on_close_modals(Message::CloseModals);

Why no PageContract?

Earlier drafts of snora required layout slots to implement a PageContract trait that declared view(), dialog(), toasts(), and close hooks. The engine never actually consumed the non-view methods, so users were forced to plumb them manually anyway, and the trait’s associated-type machinery forced all four slots to share a single type — a painful tax that produced the Section enum pattern.

v0.4 drops the trait. Every slot is a Node value of the same generic type — in practice, iced::Element<'a, Message>. Because any function can return an Element, each slot can be built by a different piece of application code without any wrapping trait or enum, and all overlay / close state lives as plain fields here.

Structs

AppLayout

The complete declarative description of what should be on screen.