Skip to content

CRUDL Views

Five view-scale layouts that form the backbone of every VUEDA application: list, create, read, update, and destroy. The new component introduced here is PageTitle, the layout-level header that displays each view's title and page actions. The scroll-aware action bars these views use to keep submit and transition controls reachable on long forms (StickyBar and the surrounding sticky-stack family) have their own page: Sticky Chrome. All other chrome — fields, field sets, alerts, ObjectsGrid, badges — is composed from earlier families.

Token surface: Color palette: light tokens.css-token:background, Color palette: light tokens.css-token:card, Color palette: light tokens.css-token:border, Color palette: light tokens.css-token:primary, Color palette: light tokens.css-token:destructive, Color palette: light tokens.css-token:muted, Color palette: light tokens.css-token:muted-foreground.

This page is the visual contract the default theme guarantees at view scale. Use it as the target spec when re-skinning. For the mechanics of overriding any of this, see Customize VUEDA Appearance.

PageTitle

PageTitle is the layout-level page header. The integrator places it once above <RouterView>; it reads the active view's title and loading state from usePageTitle (not from props) and hosts the action zone that PageActions teleports page-level buttons into. Setting sticky pins the bar to the top of the scroll viewport.

The demos below use a small DemoTitleBar wrapper that stands in for the layout: it establishes an isolated page-title context, registers a title into it, and renders the real PageTitle plus a PageActions cluster. In an application the layout owns that wiring once and each view contributes only its title and actions.

Theme keys: PageTitle.

Sticky action bars

The create, read, and update views pair PageTitle with a scroll-aware action bar that keeps the primary submit or transition controls reachable on long forms. That bar is StickyBar, and each view teleports it into the framework-owned sticky stack (via StickyChrome / StickyStackProvider) so it stacks beneath the pinned title and reveals on its own schedule. The docs harness stands in for a layout but hosts no sticky stack, so in the demos below each bar renders in place instead of pinning: the stack would take the browser window as its scroll container and float the bar over this page.

The bar primitive, the stack model, reveal strategies, and the integration contract are documented on their own page: Sticky Chrome.

ViewList

The list view is the entry point for every CRUDL resource: a title row with the create action, an under-actions bar holding search and the filter and sort entry points, a constraints band for whatever is currently applied, ObjectsGrid filling the card body, and a pagination footer.

The demo below is the live component against 28 offline records. Search, filter, sort, select rows, and page through it; every control is the real one.

ViewCreate

The create view is a page title, a sticky bar holding the submit action, and a form body rendered from the model's configured fields. The demo below is the live component.

ViewRead

The read view presents a single record in a non-editable layout: a FormModel in read view, where every field renders through WidgetReadOnly as a label/value row. Above it sits a sticky action bar of transition buttons, and the page-level actions teleport into the layout's PageTitle action zone.

The demo below is the live component. It runs through the ModelDemo harness against the same seeded customer model the create and update demos use, so the row layout, label column, and action buttons are the framework's actual output rather than an approximation.

ViewUpdate

The update view renders the same form as create, populated from the fetched record.

ViewDestroy

The destroy view is a dedicated danger page, not a modal, so it can be linked to, bookmarked, and made part of a multi-stage flow. ViewDestroy wraps a ModelActionForm in its own destructive-toned card: a banner quantifies the blast radius, the selected records are listed from the fetched instances, and an optional type-to-confirm phrase gates the submit button.

Customization surface

Token decisions flow across all five views:

Some of what a finished screen shows is a consumer addition rather than a view default:

  • ViewRead renders one flat FormModel. Grouping fields into titled sections is a customization.
  • PageActions hosts action buttons; a status badge beside the title is something the layout adds.
  • The detail action bar is generated from each record's available_actions, and each label is startCase applied to the DRF action name. Friendlier labels and extra entries come from project-defined actions, not from the view.
  • ViewDestroy's buttons read "Yes, continue" and "Cancel, go back" unless the confirm-button slot overrides them.

The highest-value theme keys for CRUDL views:

  • PageTitleroot, title, buttons. Override title to change the heading size and weight (default: text-[22px] font-semibold leading-[1.2]).
  • StickyBar and the sticky-stack keys are covered on its own page: see Sticky Chrome.
  • ObjectsGrid keys are covered on its own page: ObjectsGrid, ObjectsGridTableHeader, ObjectsGridBodyCell.
  • Field and form keys are covered on the Forms page: Field, FieldLabel, FieldContent.
  • Alert controls the form-level error banner in ViewUpdate.
  • Button — override _ButtonDestructive to restyle the delete action across destroy views without touching other button variants.

Documents matching: server v3.0.0a1.post1client v3.0.0-alpha.2