Pattern — Admin data table

*tatus* v0.1.0 — Draft. Ships alongside the ratification of rfcs/design-RFC-008-pro-opinionated-wrappers.kmd Option C (20260523). Live URL once rendered: kds.koder.dev/<locale>/patterns/patterns-admin-data-table.html.

R1 — When to use

Use this pattern when:

• A Koder admin surface lists typed records (repos, files, users,

  packages, certificates, …) with *ort + filter + select + bulk actions*ergonomics.

• The user is performing *dministrative tasks*(managing the set),

  not consuming individual records (which would call for a detail view).

• The surface lives in an admin shell with topbar + sidebar

  navigation; this pattern fills the main content area.

Do NOT use this pattern when:

• The surface is a *ashboard with widgets*— use the dashboard

  pattern (separate spec, future).

• The surface is a *ingle-record editor*— use a detail/form

  layout instead.

• The surface is a *anding page or marketing surface*— landing

  pages have their own specs under specs/landing-pages/.

• The dataset is < 50 stable rows and no filtering is needed — drop

  the toolbar entirely; render data-table primitive directly.

R2 — Composition

Vertical stack, top → bottom:

┌──────────────────────────────────────────────────────────┐
│  Page header                                             │  ← R3
│    breadcrumbs · title · subtitle · primary action       │
├──────────────────────────────────────────────────────────┤
│  Toolbar                                                 │  ← R4
│    search + filter chips · saved views · density ·       │
│    column menu · export · "+ Add filter"                 │
├──────────────────────────────────────────────────────────┤
│                                                          │
│  Data table (primitive: specs/components/data-table.kmd) │  ← R5
│    sortable columns · multi-select · bulk-action bar     │
│    sticky header · pagination/virtualization · rows      │
│                                                          │
├──────────────────────────────────────────────────────────┤
│  Footer (optional)                                       │  ← R6
│    pagination summary · count · per-page selector        │
└──────────────────────────────────────────────────────────┘

The toolbar (R4) is this pattern's *nly original contribution*— header (R3), table (R5), and footer (R6) delegate to primitives.

R3 — Page header

Spacing: header pad = --kdr-spacing-6 top + bottom; separator rule between header and toolbar = 1px --kdr-border-muted.

R4 — Toolbar (the canonical bundle)

Single horizontal row, left → right:

The first four slots are the index-filters primitive composed in-place; the last three (density / columns / export) are this pattern's additions.

When the dataset has < 50 stable rows and no filters are wired, the *ntire toolbar is omitted*and the data-table primitive renders flush with the page header.

R4.1 — Density toggle

• Two states: comfortable (default) | compact.
• Implementation: scales --kdr-table-row-height from 48px → 32px.
• Icon group (segmented control) with two icons: standard rows / dense rows.
• Selection persisted to localStorage per-tool (koder.<tool>.density).
• Aria: <div role="radiogroup" aria-label="Row density"> with two <button role="radio" aria-checked>.

R4.2 — Column visibility menu

• Trigger: icon button (columns icon, aria-label "Show/hide columns").
• Popover content: vertical list of all columns with a checkbox each;

  default-visible columns checked initially; "Reset to defaults" link at bottom.

• Hidden columns persist to localStorage pertool + persaved-view

  (koder.<tool>.<view>.columns-hidden).

• Hidden columns also hidden from export (R4.3) — what you see is

  what you export.

R4.3 — Export menu

• Trigger: icon button (download icon, aria-label "Export").
• Menu items (default): Current view as CSV, Current view as JSON,

  separator, All rows as CSV, All rows as JSON.

• "Current view" honors active filters + sort + column visibility.
• "All rows" ignores filters; honors column visibility.
• Export triggered client-side via Blob + download; large exports

  (> 10k rows) confirm before generating ("This will export 47,329 rows. Continue?").

• Perproduct optout: products MAY hide individual export items via

  config (e.g. Kdrive admin hides JSON for security review).

R5 — Data table (delegated)

The table body delegates to specs/components/data-table.kmd in full. This pattern adds *o behavioral overrides*to the primitive — what data-table.kmd specifies is what runs here. In particular:

• Bulkaction bar (datatable.kmd R3) appears in the *ame row*as

  the toolbar (R4) when ≥ 1 row is selected — toolbar slides out, bulkaction bar slides in (200ms; prefersreduced-motion: instant).

• Sticky header (data-table.kmd R4) pins below the toolbar (toolbar

  itself is sticky-page if the admin shell wants it).

• Pagination/virtualization choice (datatable.kmd R5) is pertool;

  this pattern is agnostic.

• Inline edit (datatable.kmd R8) is pertool; this pattern neither

  requires nor forbids it.

R6 — Footer (optional)

Two-element row at the bottom of the table container:

Omit the footer entirely when virtualization is on (no per-page concept) — the count moves into the page header subtitle in that case ("Repositories · 47,329 total").

R7 — Empty state

When the dataset (or current filter set) returns zero rows, render specs/patterns/empty-state.kmd *nside the table container*with appropriate copy:

• Dataset truly empty (no records exist for this account): "No

  repositories yet" + illustration + primary action ("+ New repository").

• Filter set returned zero matches: "No repositories match these

  filters" + Clear filters secondary action.

Empty state replaces table rows but does NOT replace the toolbar or header — they stay visible so the user can adjust filters or trigger the primary action.

R8 — Saved views integration

Saved views (index-filters.kmd §R4) capture *ll toolbar state* columns + sort + filters + density. Switching views updates all three regions in one navigation. URL serialization (index-filters R5) carries ?view=… plus any explicit overrides.

A view named Default is always present and not user-editable. New views are user-created via the "Save current as new view" CTA in the saved-views dropdown.

R9 — Keyboard and accessibility

Delegated to primitive specs:

• Table keyboard nav: data-table.kmd §R9
• Filter / search keyboard nav: index-filters.kmd §R6
• Table screenreader semantics: `datatable.kmd §R10`
• Filter screenreader: `indexfilters.kmd §R8`

This pattern adds:

• Cmd/Ctrl + B → focus the column-visibility button.
• Cmd/Ctrl + E → open the export menu.
• Cmd/Ctrl + D → toggle density.

Per-tool customization MAY override these accelerators; defaults apply when no override is set.

R10 — Cross-surface guidance

The pattern lands on three surfaces with the same contract:

Crosssurface parity is *wnercurated* not structurally enforced. The pattern is the contract; per-surface implementations are audited against it (separate koder-spec-audit rule once a third adopter ships).

Não-escopo

• A bundled KoderAdminTable widget that wraps everything (would

  have been Option B in RFC-008 — explicitly rejected by ratification).

• Per-product Pro variants (consumer concern; pattern sets contract only).
• Serverside data fetching, transport, caching (transportagnostic).
• Auth / permissions / row-level access (separate spec; the pattern

  assumes data already filtered by permission server-side).

• Cross-tab synchronization of saved views (out of scope; persistence

  is local).

• Theming / branding overrides (delegated to Verge presets in

  specs/themes/verge.kmd).

Re-evaluation trigger

When the *hird Koder admin tool*adopts this pattern, open a followup ticket in `tools/designgenbacklog to re-open rfcs/designRFC008proopinionated-wrappers.kmd` and consider whether Option B (SDK helper bundle) or Option A (Pro spec set) now makes sense given concrete adopter evidence. Until then, this pattern is the contract.

Current adopters (update as products ship):