Layouts are assembled from a small set of building-block components rather than hand-rolled per screen. You compose a header, footer, body, and asides out of slots and let the pieces handle the structural plumbing, so you are not rewriting the same flex and sticky-positioning math on every layout.
The set lives in shared/components/common/Layout, with Layout as the outer shell and LayoutHeader, LayoutFooter, LayoutBody, LayoutBodyContent, and LayoutBodyAside filling it in. You slot together the ones a given layout needs and leave out the rest.
Layout publishes the header and footer heights as CSS variables, --app-header-h and --app-footer-h. Everything that has to size around the chrome reads those, so a header height is declared once and the asides and body stay correct without anyone duplicating the number.
LayoutBodyAside takes a side, left or right, and a width. It sticks to the top under the header and sizes itself to the viewport minus the header and footer, so it scrolls independently of the main content and stays put as the body scrolls. Asides compose, a layout can carry both a left and a right one.
Header, footer, and body share a set of container sizes, the usual sm through xl plus full for edge-to-edge, so the content column lines up across all three. LayoutBodyContent adds a centered flag for vertical centering. Between the two you cover the common cases, auth and error pages, and logged-in screens where an initial "create your first thing" prompt or a form should sit centered rather than sprawl across the full width.
Component Architecture for why these live as composites in common/ instead of as primitives.