feat(lists): Listen-Reihenfolge per Drag-and-Drop ändern (globales position-Feld nutzen) #331

Closed
opened 2026-05-18 16:34:09 +02:00 by admin-mrrm · 1 comment
Owner

Motivation

Die Reihenfolge der Listen in der Übersicht ist aktuell fix nach createdAt ASC. Der User möchte die Sortierung selbst bestimmen — wichtige Listen oben, selten genutzte unten — über alle Bereiche (Einkaufen, Listen, Todo).

Aktueller Stand

  • DB-Schema hat bereits ein position: integer().notNull().default(0)-Feld auf lists (siehe apps/api/src/modules/lists/lists.schema.ts:28)
  • Wird im Code aber nirgends verwendetlistForOwner (lists.service.ts:24) ordnet nur nach createdAt
  • Keine Reorder-Endpoint, kein UI-Hook, kein DnD

Scope

Backend

  • lists.service.ts::listForOwner: orderBy(asc(lists.position), asc(lists.createdAt)) als Tiebreaker
  • Neuer Endpoint PATCH /lists/reorder oder POST /lists/reorder mit Body { orderedIds: string[] } → schreibt position für alle Listen des Owners in der gegebenen Reihenfolge
  • Validation: alle IDs müssen dem Owner gehören, Vollständigkeits-Check optional
  • Test: Reihenfolge bleibt nach Sync stabil; neue Liste landet ans Ende (nextPosition-Analog)

shared-types

  • DTO für Reorder-Endpoint (zod-Schema)

Mobile

  • In ListsOverviewScreen (packages/feature-lists/src/components/lists-overview-screen.tsx) Liste mit react-native-draggable-flatlist (oder vergleichbar, Expo-kompatibel) ersetzen
  • Auf Drop: lokal optimistic update + Reorder-API-Call
  • Fallback: lange drücken → ziehen (klassisches Mobile-Pattern)

Web

  • DnD-Lib einbinden (z.B. @dnd-kit/core — bereits in der App? prüfen, sonst neu)
  • Gleiche optimistic-Update-Logik wie mobile

Tests

  • Backend: Reorder-Endpoint, Position-Persistenz
  • UI-Smoke: Drop ändert Reihenfolge nach Reload

Akzeptanzkriterien

  • Reihenfolge in /einkaufen, /listen und (neu) /todo reflektiert die globale position
  • Drag-and-Drop in Mobile UND Web (CLAUDE.md: UI immer für beide)
  • Reorder bleibt nach App-Reload / Logout-Login erhalten

Verwandt

  • #112 (Einkaufen-Modus) — gemeinsamer Drawer/UX-Sprint in v0.4
  • Folge-Issue: dedizierter Todo-Bereich im Drawer (separat)
## Motivation Die Reihenfolge der Listen in der Übersicht ist aktuell fix nach `createdAt` ASC. Der User möchte die Sortierung selbst bestimmen — wichtige Listen oben, selten genutzte unten — über alle Bereiche (Einkaufen, Listen, Todo). ## Aktueller Stand - DB-Schema **hat bereits** ein `position: integer().notNull().default(0)`-Feld auf `lists` (siehe `apps/api/src/modules/lists/lists.schema.ts:28`) - Wird im Code aber **nirgends verwendet** — `listForOwner` (`lists.service.ts:24`) ordnet nur nach `createdAt` - Keine Reorder-Endpoint, kein UI-Hook, kein DnD ## Scope ### Backend - [ ] `lists.service.ts::listForOwner`: `orderBy(asc(lists.position), asc(lists.createdAt))` als Tiebreaker - [ ] Neuer Endpoint `PATCH /lists/reorder` oder `POST /lists/reorder` mit Body `{ orderedIds: string[] }` → schreibt `position` für alle Listen des Owners in der gegebenen Reihenfolge - [ ] Validation: alle IDs müssen dem Owner gehören, Vollständigkeits-Check optional - [ ] Test: Reihenfolge bleibt nach Sync stabil; neue Liste landet ans Ende (`nextPosition`-Analog) ### shared-types - [ ] DTO für Reorder-Endpoint (zod-Schema) ### Mobile - [ ] In `ListsOverviewScreen` (`packages/feature-lists/src/components/lists-overview-screen.tsx`) Liste mit `react-native-draggable-flatlist` (oder vergleichbar, Expo-kompatibel) ersetzen - [ ] Auf Drop: lokal optimistic update + Reorder-API-Call - [ ] Fallback: lange drücken → ziehen (klassisches Mobile-Pattern) ### Web - [ ] DnD-Lib einbinden (z.B. `@dnd-kit/core` — bereits in der App? prüfen, sonst neu) - [ ] Gleiche optimistic-Update-Logik wie mobile ### Tests - [ ] Backend: Reorder-Endpoint, Position-Persistenz - [ ] UI-Smoke: Drop ändert Reihenfolge nach Reload ## Akzeptanzkriterien - [ ] Reihenfolge in `/einkaufen`, `/listen` und (neu) `/todo` reflektiert die globale `position` - [ ] Drag-and-Drop in Mobile UND Web (CLAUDE.md: UI immer für beide) - [ ] Reorder bleibt nach App-Reload / Logout-Login erhalten ## Verwandt - #112 (Einkaufen-Modus) — gemeinsamer Drawer/UX-Sprint in v0.4 - Folge-Issue: dedizierter Todo-Bereich im Drawer (separat)
Author
Owner

Verwandt: #336 (App-Shell Refactor — Sidebar/Profil/Settings-Subnav, v0.4). Hauptmenü-Änderungen sollten dort koordiniert werden.

Verwandt: #336 (App-Shell Refactor — Sidebar/Profil/Settings-Subnav, v0.4). Hauptmenü-Änderungen sollten dort koordiniert werden.
Sign in to join this conversation.
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
admin-mrrm/mrrmlabapp#331
No description provided.