You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Board, Table, and Calendar collection views each independently reimplement the same "record row" rendering unit — hover-reveal open/delete buttons, PropertyValueCell, and their own local openRecordId state — instead of sharing one component. This is the same class of duplication #239 already tracks for the Document editor's block-row rendering (move handle/action menu/selection highlighting duplicated between +page.svelte and ColumnsBlock.svelte), just on the Collection-view side.
src/lib/components/CalendarCollectionView.svelte:60 (own openRecordId), the same open/delete/PropertyValueCell markup duplicated twice within the same file — month-grid cell :352-410 and list view :435-456.
All three use identical class patterns (opacity-0 transition-opacity group-hover:opacity-100) and the same icon/aria-label conventions, but there's no shared CollectionRecordRow component — CollectionViewBlock.svelte only wires connection/config, not row rendering. Nothing stops a future per-row feature (a new action, a new hover state) from needing to land in 4 places instead of 1.
Surfaced during the 2026-09-12 architecture audit (code-level scan of src/lib/components); the title-cell conditional's duplication added during #268 confirms the same file set is the fix boundary.
BoardCollectionView.svelte, TableCollectionView.svelte, and both of CalendarCollectionView.svelte's internal occurrences consume it, passing only their own container-specific layout (card vs. row vs. calendar cell)
Not in scope: #239's Document-editor block-row duplication — related pattern, different surface, tracked separately.
Done when: a new per-row action or visual state needs exactly one implementation site to reach Board, Table, and Calendar.
Priority: P2 — internal consistency/maintainability, no user-facing bug today, but the same compounding-duplication risk #239 already describes for its own surface. Added to 0.5.0 — Stability, Reliability, and QA.
Board, Table, and Calendar collection views each independently reimplement the same "record row" rendering unit — hover-reveal open/delete buttons,
PropertyValueCell, and their own localopenRecordIdstate — instead of sharing one component. This is the same class of duplication #239 already tracks for the Document editor's block-row rendering (move handle/action menu/selection highlighting duplicated between+page.svelteandColumnsBlock.svelte), just on the Collection-view side.src/lib/components/BoardCollectionView.svelte:60(ownopenRecordId), row markup:460-501— open button:482-490(aria-label="Open record"), delete button:491-499.src/lib/components/TableCollectionView.svelte:70(ownopenRecordId), row markup:208-242— identicalaria-label="Open record"/Icon name="expand"pattern:211-219,PropertyValueCell:223-228, delete button:231-240.src/lib/components/CalendarCollectionView.svelte:60(ownopenRecordId), the same open/delete/PropertyValueCellmarkup duplicated twice within the same file — month-grid cell:352-410and list view:435-456.{#if titleEditableViaCell}...{:else}...{/if}conditional (editablePropertyValueCellvs. static fallback label, per issue Board/Calendar: primary field and groupBy can point at the same field, showing redundant controls #104's collision handling) sits directly beside the markup above and is now duplicated a fourth time:BoardCollectionView.svelte:488-498, andCalendarCollectionView.svelte's own two occurrences at:392-403(scheduled) and:457-468(unscheduled).All three use identical class patterns (
opacity-0 transition-opacity group-hover:opacity-100) and the same icon/aria-label conventions, but there's no sharedCollectionRecordRowcomponent —CollectionViewBlock.svelteonly wires connection/config, not row rendering. Nothing stops a future per-row feature (a new action, a new hover state) from needing to land in 4 places instead of 1.Surfaced during the 2026-09-12 architecture audit (code-level scan of src/lib/components); the title-cell conditional's duplication added during #268 confirms the same file set is the fix boundary.
CollectionRecordRow(or similarly named) component owning the open/delete buttons,PropertyValueCellrendering, and the primary-field title cell's editable/static fallback conditional (issue Board/Calendar: primary field and groupBy can point at the same field, showing redundant controls #104'stitleEditableViaCell)BoardCollectionView.svelte,TableCollectionView.svelte, and both ofCalendarCollectionView.svelte's internal occurrences consume it, passing only their own container-specific layout (card vs. row vs. calendar cell)Not in scope: #239's Document-editor block-row duplication — related pattern, different surface, tracked separately.
Done when: a new per-row action or visual state needs exactly one implementation site to reach Board, Table, and Calendar.
Priority: P2 — internal consistency/maintainability, no user-facing bug today, but the same compounding-duplication risk #239 already describes for its own surface. Added to 0.5.0 — Stability, Reliability, and QA.