DataTable was strong, but its admin workflows were incomplete

⁠Build log series⁠: I hand a real screen to an AI that has never seen Gunjo (@gunjo/ui) and let it build. This round covered an ⁠admin CRUD dashboard⁠.

I again limited the agent to the shipped npm package and docs site. Inside a sidebar and top-bar shell, the assignment called for ⁠a KPI row, data table (status badges, row selection, bulk actions, row menus, sorting, and pagination), compound filters, an edit Sheet, empty and loading states, and toasts.⁠ Unlike the charts in #4 or the plain table in #6, this tested a ⁠dense data-manipulation workflow⁠.

Result: around 3.5/5, carried by a strong data layer

⁠ActionDataTable and DataTable did most of the work.⁠ They handled row selection, bulk actions, sorting, pagination, and custom Badge cells with ⁠no hand-rolled <table>.⁠ The output used a real <table> and exactly one h1. Selection used labeled role="checkbox" buttons plus aria-checked="mixed", ⁠which made that interaction genuinely accessible.⁠ EmptyState, editing through Sheet and Form, Sidebar plus Drawer, Statistic, and Toast also composed successfully. ⁠tsc reported no errors and the build passed.⁠ The low-level and middle layers were ready for real work.

The friction came from the advanced DataTable APIs needed for ⁠established admin interaction patterns.⁠ I addressed each finding below.

What I fixed: admin interaction patterns in DataTable

⁠1. Accessibility: <th> had no scope, and sortable columns had no aria-sort (issue #123).⁠ The component rendered a real table, but screen readers could not associate column headers or announce the current sort. I added scope="col" and a contextual aria-sort value (none, ascending, or descending). A browser check confirmed that clicking the header changed aria-sort. This was the DataTable version of the recurring accessibility class.

⁠2. Omitting filter produced a console warning (issue #124).⁠ Even <DataTable data columns /> called getColumn("") and emitted [Table] Column with id '' does not exist. I changed the default to leave filtering off.

⁠3. Admin-table interactions were missing (issue #125).⁠ Selection was locked inside the component, there was no onRowClick, and rowActions supported only inline icons. The agent had to hand-roll the common row overflow menu. I added ⁠controlled selection (selectedIds and onSelectionChange), onRowClick, and rowActionsVariant="menu" backed by DropdownMenu.⁠

⁠4. Filtering supported only text on one column (issue #126).⁠ The agent could not combine a status Select, date, and search term, so it calculated the filtered rows before passing them to DataTable. The compound-filter API went to the beta gate.

What I took away: the data layer and admin interaction patterns are separate

Data layer (rows, columns, selection, sorting, pagination, and cells): ready for real work, with no hand-rolled table
Admin interactions (controlled state, row clicks, an overflow menu, compound filters, and accessible th elements): incomplete

The issue was not a crash or broken layout. It was whether the design system encoded ⁠the standard interactions of a dense admin UI⁠ in its API. A strong low-level layer made the missing higher-level conventions easier to see. I shipped the first three fixes in this session and moved the fourth, which required API design, to the beta gate. The recurring accessibility work also continued through table headers and sorting.

Next up: build log #25

• ⁠A pricing comparison, error page, or calendar schedule⁠, continuing to test composition and established interaction patterns.

The run

• ⁠gunjo.jp⁠ / npm @gunjo/ui / ⁠GitHub⁠
• Earlier rounds: #1 through #23
• Overview: Gunjo (@gunjo/ui) / Why it exists: Design systems in the age of AI
• ⁠GunjoUI by UIXHERO⁠

Gunjo was still in early alpha at the time; issues are welcome.