#113 — Kamera-basiertes Barcode-Scannen auch für die Einkaufsliste (gemeinsame Komponente) #116

New issue

Closed

opened 2026-08-18 13:14:13 +02:00 by lena · 0 comments

lena commented

2026-08-18 13:14:13 +02:00

(Migrated from git.butzei.de)

Story: Kamera-basiertes Barcode-Scannen auch für die Einkaufsliste (gemeinsame Komponente)

As a Nutzer der Einkaufsliste,
I want to Barcodes per Handy-Kamera scannen können, so wie es im Vorratsschrank (#94) bereits funktioniert,
statt die Nummer eintippen zu müssen,
so that ich beim Einkaufen/Auffüllen genauso schnell scannen kann wie im Vorratsschrank, ohne ein separates
Scanner-Gerät zu brauchen.

Depends on: keine (#90 und #94 sind beide bereits geliefert).

Hintergrund: Aktuell ist die Kamera-Anbindung uneinheitlich zwischen den beiden Listentypen:

PantryBarcodeScanner.tsx (#94) scannt bereits live über die Geräte-Kamera via @zxing/browser
(BrowserMultiFormatReader + getUserMedia-Videostream), mit Fallback auf ein Textfeld, falls Kamera/
Permission/Secure-Context fehlen.
ShoppingBarcodeScanDialog.tsx (#90) ist bewusst rein textbasiert geblieben — die Design-Entscheidung in
90_shopping_list_upgrades_design.mds "Scope-Entscheidungen" begründet das damit, dass physische
Barcode-Scanner (Hardware) eine Tastatur emulieren und daher ohne Kamera-Code funktionieren. Dieselbe Notiz
hält aber ausdrücklich fest, dass Kamera-Scan mit #94 "für beide Listentypen nutzbar" werden sollte
(gemeinsames Barcode-Feld) — das wurde nach Auslieferung von #94 nie nachgezogen.

Diese Story schließt die Lücke, indem die bestehende Kamera-Logik aus #94 wiederverwendet statt neu gebaut wird.

Acceptance criteria:

Die Kamera-Scan-Logik aus PantryBarcodeScanner.tsx (Video-Element, zxing-Decode-Loop,
Permission-/Kamera-Fehler-Fallback) wird in eine gemeinsame Komponente/einen Hook extrahiert, die/der von
beiden Dialogen genutzt wird — ohne Verhaltensänderung für den bestehenden Vorratsschrank-Scan.
ShoppingBarcodeScanDialog bekommt dieselbe Live-Kamera-Ansicht wie der Vorratsschrank; ein erfolgreicher
Scan löst denselben Ablauf aus wie heute das Eintippen + Enter (bestehender
ScanShoppingProductBarcodeCommand-Flow bleibt unverändert, inkl. Kategorie-Nachfrage aus #104).
Ist die Kamera nicht verfügbar (Permission verweigert, kein Kamera-Zugriff, kein Secure Context), fällt
der Dialog wie im Vorratsschrank sauber auf das bestehende Textfeld zurück — kein Dead End.
Der bestehende Weg über physische, tastatur-emulierende Scanner-Hardware (Zahlen tippen + Enter)
funktioniert unverändert weiter.

Out of scope for this story:

Verifikation auf einem echten Mobilgerät (Kamera-Zugriff über HTTPS/Secure-Context, tatsächliche
Scan-Zuverlässigkeit) — das ist reine Verifizierung bereits gebauter Funktionalität und gehört in #96s
gebündelte Mobile-/Touch-Verifizierungsrunde, nicht in diese Bau-Story. #96 wird um diesen Punkt (Vorratsschrank
und Einkaufsliste) ergänzt.
Änderungen an der Barcode-Lookup-/OpenFoodFacts-Logik selbst — nur die Scan-UI wird vereinheitlicht.

# Story: Kamera-basiertes Barcode-Scannen auch für die Einkaufsliste (gemeinsame Komponente) **As a** Nutzer der Einkaufsliste, **I want to** Barcodes per Handy-Kamera scannen können, so wie es im Vorratsschrank (`#94`) bereits funktioniert, statt die Nummer eintippen zu müssen, **so that** ich beim Einkaufen/Auffüllen genauso schnell scannen kann wie im Vorratsschrank, ohne ein separates Scanner-Gerät zu brauchen. **Depends on:** keine (`#90` und `#94` sind beide bereits geliefert). **Hintergrund:** Aktuell ist die Kamera-Anbindung uneinheitlich zwischen den beiden Listentypen: - `PantryBarcodeScanner.tsx` (`#94`) scannt bereits live über die Geräte-Kamera via `@zxing/browser` (`BrowserMultiFormatReader` + `getUserMedia`-Videostream), mit Fallback auf ein Textfeld, falls Kamera/ Permission/Secure-Context fehlen. - `ShoppingBarcodeScanDialog.tsx` (`#90`) ist bewusst rein textbasiert geblieben — die Design-Entscheidung in `90_shopping_list_upgrades_design.md`s "Scope-Entscheidungen" begründet das damit, dass physische Barcode-Scanner (Hardware) eine Tastatur emulieren und daher ohne Kamera-Code funktionieren. Dieselbe Notiz hält aber ausdrücklich fest, dass Kamera-Scan mit `#94` "für beide Listentypen nutzbar" werden sollte (gemeinsames Barcode-Feld) — das wurde nach Auslieferung von `#94` nie nachgezogen. Diese Story schließt die Lücke, indem die bestehende Kamera-Logik aus `#94` wiederverwendet statt neu gebaut wird. **Acceptance criteria:** - [ ] Die Kamera-Scan-Logik aus `PantryBarcodeScanner.tsx` (Video-Element, zxing-Decode-Loop, Permission-/Kamera-Fehler-Fallback) wird in eine gemeinsame Komponente/einen Hook extrahiert, die/der von beiden Dialogen genutzt wird — ohne Verhaltensänderung für den bestehenden Vorratsschrank-Scan. - [ ] `ShoppingBarcodeScanDialog` bekommt dieselbe Live-Kamera-Ansicht wie der Vorratsschrank; ein erfolgreicher Scan löst denselben Ablauf aus wie heute das Eintippen + Enter (bestehender `ScanShoppingProductBarcodeCommand`-Flow bleibt unverändert, inkl. Kategorie-Nachfrage aus `#104`). - [ ] Ist die Kamera nicht verfügbar (Permission verweigert, kein Kamera-Zugriff, kein Secure Context), fällt der Dialog wie im Vorratsschrank sauber auf das bestehende Textfeld zurück — kein Dead End. - [ ] Der bestehende Weg über physische, tastatur-emulierende Scanner-Hardware (Zahlen tippen + Enter) funktioniert unverändert weiter. **Out of scope for this story:** - Verifikation auf einem echten Mobilgerät (Kamera-Zugriff über HTTPS/Secure-Context, tatsächliche Scan-Zuverlässigkeit) — das ist reine Verifizierung bereits gebauter Funktionalität und gehört in `#96s` gebündelte Mobile-/Touch-Verifizierungsrunde, nicht in diese Bau-Story. `#96` wird um diesen Punkt (Vorratsschrank *und* Einkaufsliste) ergänzt. - Änderungen an der Barcode-Lookup-/OpenFoodFacts-Logik selbst — nur die Scan-UI wird vereinheitlicht.