design-RFC-008 — Pro opinionated wrappers over primitives

ratified

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)*20260523. Pattern shipped at specs/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 .kmd spec under

    meta/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 the

    bundled 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

Source: ../home/koder/dev/koder/meta/docs/stack/rfcs/design-RFC-008-pro-opinionated-wrappers.kmd