Frontend: drag-and-drop reorder buckets within a scenario #66

New issue

Open

opened 2026-07-06 21:28:36 +02:00 by myrmidex · 0 comments

myrmidex commented

2026-07-06 21:28:36 +02:00

Owner

Context

On the scenario show page (/scenarios/:id), buckets render in sortOrder ASC order (embedded via #64). Today a user has no way to change that order — sortOrder is read-only on the API (bucket:read group only, not writable) and there's no UI to reorder.

This ticket adds drag-and-drop reordering of buckets within a scenario, persisting the new sortOrder.

Deferred — not v0.3.0. Polish for a later milestone (triage into one when picked up).

Scope

Frontend

Drag-and-drop the bucket cards on the scenario show page to reorder them.
On drop, persist the new order to the backend, then reflect the server-truth order (refetch or optimistic-with-rollback).
Accessible: provide a keyboard-operable reorder affordance too (DnD alone is not accessible).

Backend

Expose a way to persist reordered sortOrder — currently sortOrder is not in any write group and Bucket PATCH (#57) does not accept it. Options to decide during scoping:
- Add sortOrder to a Bucket write group so PATCH can set it (N PATCHes, or one per moved bucket), or
- A dedicated batch reorder endpoint on the scenario (e.g. PATCH /api/scenarios/{id}/bucket-order taking an ordered list of bucket IRIs) — atomic, one request.
Recommend the batch endpoint: reordering is inherently a whole-list operation and avoids transient duplicate/gap states across N PATCHes.
Enforce ownership (only the scenario owner can reorder) and that all referenced buckets belong to that scenario.

Design questions (resolve during scoping)

Batch reorder endpoint vs. per-bucket PATCH of sortOrder.
sortOrder semantics: dense contiguous integers re-written on every reorder, vs. sparse/fractional to allow single-item moves. Recommend dense-rewrite for simplicity given small bucket counts.
DnD library choice (e.g. dnd-kit) vs. hand-rolled — keep the scaffolding footprint low per project preference.

Depends on

#53 (scenario show page hosting the bucket list) — done.
#64 (buckets embedded with sortOrder) — done.

Out of scope

Reordering scenarios themselves (scenarios have no sortOrder).
Reordering streams.

Testing

Backend: reorder persists new sortOrder; ownership + same-scenario invariants return the right status; embedded read reflects new order.
Frontend: RTL for the reorder interaction (keyboard path at minimum; DnD via library test utils) + the persistence call; e2e smoke deferred (same scenario-seeding fixture gap as #54).

## Context On the scenario show page (`/scenarios/:id`), buckets render in `sortOrder ASC` order (embedded via #64). Today a user has no way to change that order — `sortOrder` is read-only on the API (`bucket:read` group only, not writable) and there's no UI to reorder. This ticket adds drag-and-drop reordering of buckets within a scenario, persisting the new `sortOrder`. **Deferred — not v0.3.0.** Polish for a later milestone (triage into one when picked up). ## Scope ### Frontend - Drag-and-drop the bucket cards on the scenario show page to reorder them. - On drop, persist the new order to the backend, then reflect the server-truth order (refetch or optimistic-with-rollback). - Accessible: provide a keyboard-operable reorder affordance too (DnD alone is not accessible). ### Backend - Expose a way to persist reordered `sortOrder` — currently `sortOrder` is not in any write group and Bucket PATCH (#57) does not accept it. Options to decide during scoping: - Add `sortOrder` to a Bucket write group so PATCH can set it (N PATCHes, or one per moved bucket), **or** - A dedicated batch reorder endpoint on the scenario (e.g. `PATCH /api/scenarios/{id}/bucket-order` taking an ordered list of bucket IRIs) — atomic, one request. - Recommend the batch endpoint: reordering is inherently a whole-list operation and avoids transient duplicate/gap states across N PATCHes. - Enforce ownership (only the scenario owner can reorder) and that all referenced buckets belong to that scenario. ## Design questions (resolve during scoping) - Batch reorder endpoint vs. per-bucket PATCH of `sortOrder`. - `sortOrder` semantics: dense contiguous integers re-written on every reorder, vs. sparse/fractional to allow single-item moves. Recommend dense-rewrite for simplicity given small bucket counts. - DnD library choice (e.g. dnd-kit) vs. hand-rolled — keep the scaffolding footprint low per project preference. ## Depends on - #53 (scenario show page hosting the bucket list) — done. - #64 (buckets embedded with `sortOrder`) — done. ## Out of scope - Reordering scenarios themselves (scenarios have no `sortOrder`). - Reordering streams. ## Testing - Backend: reorder persists new `sortOrder`; ownership + same-scenario invariants return the right status; embedded read reflects new order. - Frontend: RTL for the reorder interaction (keyboard path at minimum; DnD via library test utils) + the persistence call; e2e smoke deferred (same scenario-seeding fixture gap as #54).