design-RFC-008 — Pro opinionated wrappers over primitives
Evaluated whether KDS should introduce a **Pro layer** above its primitive components — pre-bundled toolbars, saved views, density toggles, column visibility menus, export hooks — to spare every Koder admin tool (Forge, Kdrive admin, Hub publisher, …) from re-wiring the same boilerplate. **Ratified Option C (recipe doc only)** on 2026-05-23 — see `specs/patterns/admin-data-table.kmd`. Re-evaluation trigger documented in R5: when a third admin tool re-derives the same toolbar, re-open this RFC.
designRFC008 — Pro opinionated wrappers
*tatus* v0.1.0 *atified Option C (recipe doc)*2026
0523. Pattern shipped atspecs/patterns/admin-data-table.kmd. Reevaluation trigger (R5): when a third admin tool rederives the toolbar, re-open this RFC to consider Option B or Option A for the next Verge generation.
R1 — Problem
KDS today ships the *rimitive layer*
specs/components/data-table.kmd— sortable columns, multi-select,bulk-action bar, sticky header, pagination/virtualization, saved views, expandable rows, inline edit, keyboard nav, OUIA hooks.
specs/components/index-filters.kmd— search + filter chips +saved-views dropdown, URL serialization, persisted named views.
Each Koder admin tool that lists typed records (Forge repo list, Kdrive folder browser, Hub publisher catalog, future Koder ID admin, …) ends up wiring the *ame toolbar of search + filters + density toggle + column visibility menu + export button*on top of those primitives. The work is real, repetitive, and currently diverges per-product — Forge's density toggle does not match Kdrive's column menu, which does not match Hub's export workflow.
Ant Design solves this with *roComponents*
Table ← unopinionated primitive (Ant: Table; Koder: KoderDataTable)
ProTable ← bundles search + saved views + density + column menu + export
ProForm ← bundles labeled controls + steps + validation + submit toolbar
ProList ← list flavor with same toolbar bundle
ProDescriptions ← read-only key/value pair grid
ProLayout ← shell scaffold (sidenav + topbar + breadcrumbs)Each Pro variant *akes in*the common-case bundle so adopters can pick the layer that matches their need. KDS has the primitive layer; the bundle layer does not exist as a contract — every product re- derives it.
R2 — Prior art
Ant ProComponents — Proaspublished-library
ProComponents ships as a separate npm package (@ant-design/pro-components) on top of antd. Each Pro variant is its own component (ProTable, ProForm, ProList). Consumers import either Table (primitive) or ProTable (bundled) at choice. The Pro library evolves on its own release cadence; the primitive does not move when the Pro contract changes.
Material 3 — Proasoutofscope
Material 3 publishes the primitive (DataTable) and an extensive guidance corpus ("Patterns" — how to compose toolbar + filters + density). No bundled Pro component. Consumers compose primitives themselves following the guidance.
PatternFly — Proasrecipe + Composable Toolbar
PatternFly ships Table, Toolbar, and Toolbar*Group primitives separately, plus a Composable Table recipe in the docs site that demonstrates the canonical stack. No bundled component; the recipe is the contract.
Polaris — ProasIndexTable
Polaris collapses the Pro concept into IndexTable directly — there is no "primitive" Table. Saved views, bulk actions, and filters ship as parts of one component. Consumers cannot opt out of the toolbar; the bundle is the only API.
Carbon — Proashelper + DataTable.SectionHeader
Carbon ships DataTable (primitive) plus several helpers (DataTable.Toolbar, DataTable.SearchBar, DataTable.OverflowMenu) that compose into a Pro shape on the consumer side. Closer to Ant's "ProTable" than to Material's "compose yourself" but lighter than Polaris's "no choice".
| Library | Pro layer | Where it lives | Consumer ergonomics |
|---|---|---|---|
| Ant | Yes — ProTable |
Separate npm package | Pick primitive OR Pro at import |
| Material 3 | No | Guidance docs | Compose primitives per pattern doc |
| PatternFly | No (recipe in docs) | Docs site | Copy recipe, compose primitives |
| Polaris | Pro-only (IndexTable) |
Same package, only API | No opt-out |
| Carbon | Helpers (Toolbar, SearchBar) |
Same package | Compose helpers around primitive |
R3 — Options
Option A — Proasspec (specspatternspro-table.kmd)
*echanics*
- Each Pro variant is its own
.kmdspec undermeta/docs/stack/specs/patterns/pro-table.kmd,pro-form.kmd,pro-list.kmd,pro-descriptions.kmd,pro-layout.kmd. - Specs reference the primitive (
data-table.kmd) and add thebundled requirements: saved views section, density toggle, column visibility menu, export hook contract, default toolbar arrangement.
- No code ships from this RFC — the *pec*is the contract; each
consumer (
koder_kit,koder_web_kit,templ-based landings) implements the Pro spec in its own surface. - Verge sister spec governs visual rendering (toolbar slot order,
density token swap, dropdown alignment).
*ros*
- KDS preserves the "spec is the contract" pattern that all other
components follow (`specs/components