Two adjacent advanced data-table patterns: spreadsheet-style cells the user can edit inline (06i) and hierarchical rows with expand/collapse (06j). Both compose existing primitives — `<table-ui>` for the grid, `<tree-ui>` for the hierarchy.
Inline-edit grids: when the user spends most of their time correcting/refining row data — pricing matrices, inventory counts, bulk metadata editing. Distinct from a detail drawer (12b) which is for one-row-at-a-time depth. Tree tables: when rows are recursively nested and the hierarchy is the data — org charts, file trees, accounting categories. Distinct from a flat table with a parent-id column.
The most common shape: a normal table where one row at a time enters edit mode (double-click or pencil button). Cells become `<input-ui>` / `<select-ui>` / etc.; Save / Cancel actions appear in the row's trailing column.
| Plan | Price | Limits | |
|---|---|---|---|
|
|
|||
The full Excel-style shape: every cell renders an `<input-ui>` (or typed equivalent — number, select, date). Tab moves to the next cell, Enter commits + moves down. Saves are auto-debounced; the dirty state surfaces as a per-row tag.
| Item | Oct | Nov | Dec | Status |
|---|---|---|---|---|
Use <tree-ui> for the recursion. Each <tree-item-ui> renders the chevron + indent automatically; nested items go inside the parent's default slot. Common in budgets, org charts, file browsers.
--a-bg-subtle background makes the active row obvious. Without it, users lose track of which row they're editing after scrolling.tag-ui variant="warning">dirty trailing tag tells the user which rows have unsaved changes. Per-cell highlighting is too noisy.