hazo_ui 6.4.0 → 6.7.0

package/CHANGE_LOG.md

@@ -5,6 +5,124 @@ All notable changes to this project will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## v6.7.0 (2026-08-02)
+
+### Added — `data-column-key` / `data-lane-key` on the kanban DOM
+
+`cls_hazo_kanban_column` is one class shared by every column, so a consumer
+whose columns carry meaning — an inbox is not a done pile — had no way to
+style one differently. The only lever available was `:nth-child`, which
+silently mis-paints the moment columns are reordered, filtered, or a lane
+renders a subset. These attributes make the identity the component already
+knows about addressable from CSS:
+
+| Element | Attributes |
+|---|---|
+| `.cls_hazo_kanban_column` | `data-column-key`, `data-lane-key` |
+| `.cls_hazo_kanban_column_head` | `data-column-key`, `data-lane-key` |
+| `.cls_hazo_kanban_column_body` | `data-column-key`, `data-lane-key` |
+| `.cls_hazo_kanban_card` | `data-column-key`, `data-lane-key`, `data-section-key` |
+
+`data-lane-key` is absent (not empty) on an unlaned board, so
+`[data-lane-key]` is a usable "is this board laned" test. Both layout trees
+always render — pair with the ancestor `.cls_hazo_kanban_desktop` /
+`.cls_hazo_kanban_mobile` when a rule must apply to only one.
+
+Purely additive: no class, layout, or default paint changed.
+
+### Added — `--hazo-kanban-card-shadow`
+
+Cards drew `background: hsl(var(--hazo-kanban-card-bg))` with a 1px border
+and nothing else. Under any palette where `--card` and `--background` resolve
+to the same value (the shadcn-derived default in `hazo_theme`, in both light
+and dark), that border is the *only* thing separating a card from the column
+behind it, and the board reads as flat.
+
+The card's `box-shadow` now resolves `var(--hazo-kanban-card-shadow, none)`.
+The fallback is `none`, so a consumer that never declares the token renders
+byte-identically to v6.6.0. Set it (e.g. to `var(--shadow-sm)`) to give cards
+a real lift.
+
+## v6.6.0 (2026-08-02)
+
+### Added — consumer slots on a laned `HazoUiKanban`
+
+v6.5.0 gave the board a second, outer axis but no way to hang anything off
+it. A lane could be dropped into and counted, and that was all — there was no
+supported place to put "add an item to this lane", a per-lane overflow menu,
+or an inline composer at the foot of a column. Both slots below are additive
+and default to rendering nothing, so existing boards are byte-identical.
+
+- **`KanbanLane.actions?: React.ReactNode`** — rendered in the lane heading
+  between the rule and the count, and right-aligned on a `collapseWhenEmpty`
+  lane's drop strip so a lane's controls do not vanish the moment it empties.
+  No `stopPropagation` is needed on controls placed here: a lane heading is a
+  `useDroppable` node, which registers a rect but attaches no pointer
+  handlers, unlike the `useSortable` card shell.
+- **`HazoUiKanbanProps.renderColumnFooter?: (ctx) => React.ReactNode`** —
+  rendered under a column body, below the cards or the `emptyColumn`
+  placeholder. `ctx` is `{ columnKey, laneKey }` and the function is called
+  once per rendered copy of a column, so on a laned board it fires once per
+  (lane, column) pair — enough to build a composer scoped to one lane's
+  Inbox. Return `null` for the columns that should not have one.
+  - The footer sits inside the column's droppable but **outside** its
+    `SortableContext`, so it never joins the sort order or becomes a drop
+    target of its own.
+  - The unmatched-lane row is deliberately skipped: its lane key is the
+    private `__hazo_lane_unmatched__` sentinel, never a lane the consumer
+    declared, so a footer there would both leak an internal constant and ask
+    for controls scoped to a lane that does not exist.
+
+New class hooks: `cls_hazo_kanban_lane_actions`,
+`cls_hazo_kanban_column_footer`. The lane strip's title is now wrapped in its
+own `cls_hazo_kanban_lane_title` span (it was a bare text node) so the
+right-aligned actions have something to sit beside.
+
+See `test-app/app/kanban/` §12.
+
+## v6.5.0 (2026-08-02)
+
+### Added — swimlanes for `HazoUiKanban`
+
+A board can now declare `lanes`, rendering one full-width row per lane —
+a wide lane heading, then that lane's own copy of the whole column grid. Where
+`sections` (v6.4.0) group *within* a column, lanes group *across* all of them,
+so the second axis can be the row axis instead of the inner one.
+
+- `HazoUiKanbanProps.lanes?: KanbanLane[]` — `{ key, title, accepts?,
+  collapseWhenEmpty? }`. Cards are placed by the new `KanbanItem.laneKey`.
+  Omit `lanes` and nothing changes: existing boards render exactly as before.
+- `KanbanMoveEvent` gained `fromLane`/`toLane`; `KanbanReorderEvent` gained
+  `laneKey`. Move-vs-reorder is now decided on all three axes — same column,
+  section *and* lane is a reorder; changing any one is a move.
+- **A lane heading is the lane-only drop target.** It carries a lane but no
+  column, read as "change the lane, keep the card's column" — the mirror of a
+  sectioned column's head ("change the column, keep the section").
+- `collapseWhenEmpty` renders a lane with no cards as a thin full-width dashed
+  strip, which is what makes "declare every lane" affordable for a long
+  vocabulary. A card whose `laneKey` matches no declared lane renders in an
+  unlabelled trailing lane rather than disappearing.
+- The optimistic overlay tracks the destination lane too, so a cross-lane drop
+  moves immediately instead of snapping back until the consumer's async commit
+  lands.
+
+### Fixed — drops landed in the wrong column on tall or scrolled boards
+
+Two long-standing defects in drop resolution, both of which lanes made
+impossible to miss:
+
+- **Collision detection is now pointer-first** (`pointerWithin`, falling back
+  to `rectIntersection`, then `closestCorners`). `closestCorners` alone
+  averages the distance to all four corners, so a column stretched tall by a
+  neighbour's card stack scored *worse* than a short, far-away column — a drop
+  well inside the right column could resolve to a different one entirely.
+  Keyboard drags have no pointer and take the same fallbacks as before.
+- **Droppable ids are scoped per layout tree.** The mobile tab strip and the
+  desktop grid both always render (CSS hides one), so every column previously
+  registered twice under one id. dnd-kit keys its registry by id, so one node
+  won and collisions were measured against the CSS-hidden copy's 0×0 rect.
+  Ids now carry the tree ("m"/"d") and, on a laned board, the lane.
+
 ## v6.4.0 (2026-08-01)
 
 ### Added — in-column sections for `HazoUiKanban`

package/README.md

@@ -3677,6 +3677,48 @@ function Actions({ initial }) {
 event carries `revert()` — call it when your API request fails and the
 overlay snaps back to whatever `items` says.
 
+### Grouping: sections (v6.4.0) and swimlanes (v6.5.0)
+
+A board can group on a second axis, either *inside* each column or *across*
+all of them. Both are opt-in; omit them and the board is a plain column grid.
+
+```tsx
+// Sections: separator-headed bands inside each column, keyed by item.sectionKey
+<HazoUiKanban
+  columns={COLUMNS.map(col => ({
+    ...col,
+    sections: TAGS.map(t => ({ key: t, title: t, collapseWhenEmpty: true })),
+  }))}
+  items={items.map(it => ({ ...it, sectionKey: it.tag }))}
+  onMove={(e) => save(e.itemId, { column: e.toColumn, tag: e.toSection })}
+  renderCard={renderCard}
+/>
+
+// Swimlanes: one full-width row per lane, each with its own column grid,
+// keyed by item.laneKey
+<HazoUiKanban
+  columns={COLUMNS}
+  lanes={TAGS.map(t => ({ key: t, title: t, collapseWhenEmpty: true }))}
+  items={items.map(it => ({ ...it, laneKey: it.tag }))}
+  onMove={(e) => save(e.itemId, { column: e.toColumn, tag: e.toLane })}
+  renderCard={renderCard}
+/>
+```
+
+| | Sections | Lanes |
+|---|---|---|
+| Declared on | `KanbanColumn.sections` | `HazoUiKanbanProps.lanes` |
+| Card placed by | `KanbanItem.sectionKey` | `KanbanItem.laneKey` |
+| Renders as | bands stacked inside one column | full-width rows, each with the whole column grid |
+| Move event carries | `fromSection`/`toSection` | `fromLane`/`toLane` |
+| "Keep the other axis" drop target | the column head | the lane heading |
+| `collapseWhenEmpty` | thin drop strip at the column's foot | full-width drop strip |
+
+A drop expresses both axes at once, so one gesture can change status and tag
+together. `accepts(item)` on a column, section or lane rejects a drop into it.
+Cards whose key matches nothing declared render in an unlabelled trailing
+group (sections) or lane row (lanes) rather than disappearing.
+
 ### Theming (CSS custom properties)
 
 | Variable | Default | Purpose |