Content
View differences
Updated by Alexander Coles about 17 hours ago
Should Angular components that use drag and drop be migrated to the Pragmatic-based `sortable-lists` foundation, or stay on Dragula until each surface gets its Angular → Rails/Hotwire rewrite? Rough thoughts:
This gates step 4 of the rollout plan in #DREAM-677 — and, transitively, when the `dragula` npm dependency can be removed.
### Inventory (as of 2026-07)
**Dragula-based, via the shared Angular `DragAndDropService`** (`frontend/src/app/shared/helpers/drag-and-drop/drag-and-drop.service.ts`):
* Boards — `board-list.component.ts`, `board-list-container.component.ts`, `board-partitioned-page.component.ts`
* Work-package table reorder / card view / grid — `drag-and-drop-transformer.ts`, `wp-card-view.component.ts`, `wp-grid.component.ts`
* Team planner calendar — `calendar-drag-drop.service.ts`
* BIM BCF list — `bcf-list.component.ts`
* Draggable autocompleter — `draggable-autocomplete.component.ts`
* Dashboards / grids widgets — grids module
**Angular CDK drag-drop based — explicitly out of scope** (stays on CDK until the surface itself Yes, if there is rewritten):
* Board column reordering — `board-list-container.component.ts` (`CdkDragDrop`)
* Grids module drag handles
### Decision criteria
Migrate an Angular Dragula surface to the new foundation only if **both** hold:
1. A existing, supported integration path between Pragmatic DnD / `sortable-lists` and the with Angular component exists, **or**
* OR creating one an integration is trivial (< "trivial" (< a few hours of work).
2. The surface is not already scheduled for an Angular → Rails/Hotwire rewrite that would make the DnD migration throwaway work. work)
No otherwise
Otherwise: leave the surface on Only migrate Dragula until its rewrite, and accept that `dragula` cannot be dropped from `package.json` (#DREAM-677 step 5) while any Angular consumer remains. components - not CDK
### Open questions
* Boards: DnD migration in place vs. waiting for a full Hotwire rewrite of boards — which comes first on the roadmap?
* Does the Turbo morph guard approach even apply inside Angular-managed DOM, or would an Angular integration need its own registration lifecycle for Pragmatic's element attributes? <br>
This gates step 4 of the rollout plan in #DREAM-677 — and, transitively, when the `dragula` npm dependency can be removed.
### Inventory (as of 2026-07)
**Dragula-based, via the shared Angular `DragAndDropService`** (`frontend/src/app/shared/helpers/drag-and-drop/drag-and-drop.service.ts`):
* Boards — `board-list.component.ts`, `board-list-container.component.ts`, `board-partitioned-page.component.ts`
* Work-package table reorder / card view / grid — `drag-and-drop-transformer.ts`, `wp-card-view.component.ts`, `wp-grid.component.ts`
* Team planner calendar — `calendar-drag-drop.service.ts`
* BIM BCF list — `bcf-list.component.ts`
* Draggable autocompleter — `draggable-autocomplete.component.ts`
* Dashboards / grids widgets — grids module
**Angular CDK drag-drop based — explicitly out of scope** (stays on CDK until the surface itself
* Board column reordering — `board-list-container.component.ts` (`CdkDragDrop`)
* Grids module drag handles
### Decision criteria
Migrate an Angular Dragula surface to the new foundation only if **both** hold:
1. A
* OR
2. The surface is not already scheduled for an Angular → Rails/Hotwire rewrite that would make the DnD migration throwaway work.
No otherwise
Otherwise: leave the surface on
### Open questions
* Boards: DnD migration in place vs. waiting for a full Hotwire rewrite of boards — which comes first on the roadmap?
* Does the Turbo morph guard approach even apply inside Angular-managed DOM, or would an Angular integration need its own registration lifecycle for Pragmatic's element attributes?