Files
MABEA/frontend/README.md
T
patrickandClaude Sonnet 5 e0cbf4b8de
CI / backend-tests (push) Successful in 1m6s
CI / frontend-build (push) Successful in 18s
Playwright-E2E-Tests für die PWA (Login, Sperrlogik, Fortschritt, Offline-Queue)
Läuft komplett gegen gemockten Backend (e2e/mockApi.ts, page.route) - kein
echtes Backend/DB nötig, playwright.config.ts startet npm run dev automatisch.
Deckt Login-Erfolg/-Fehler, 409-Objektsperre mit Übernahme, hochzählende
Fortschrittsanzeige und Offline-Queue-Verhalten (kein Request während offline,
Sync bei Reconnect) ab.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CVgbozhYmuEhiEJHffRXCV
2026-09-04 18:08:08 +02:00

53 lines
2.4 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# MABEA Frontend Sprint 7
React + Vite PWA. Deckt Prompt 11 Screens 1-6 (kompakt zusammengefasst: Objektliste,
Kontrolle mit Positionserfassung, Abschluss/Abbruch) und Prompt 17 (Offline-Härtung:
IndexedDB-Queue, Statusanzeige je Position, Abschluss blockiert bis alles gespeichert) ab.
## Setup (auf dem Zielsystem, nicht lokal)
```bash
npm install
cp example.env .env
# .env: VITE_API_BASE_URL auf die Backend-URL setzen
npm run build
```
`npm run build` erzeugt `dist/` inkl. Service Worker (vite-plugin-pwa) - dieser Ordner
wird vom Reverse-Proxy (nginx) ausgeliefert, siehe `deploy/`.
## Fehlende Assets vor Produktivbetrieb
- `public/icon-192.png`, `public/icon-512.png` (PWA-Manifest-Icons) müssen noch ergänzt
werden - aktuell nur in `vite.config.ts` referenziert, keine echten Bilddateien vorhanden.
## Architektur-Entscheidungen (Sprint 7)
- **Offline-Queue** (`src/offline/queue.ts`): IndexedDB statt reinem Service-Worker-Cache,
weil tatsächliche Formulardaten (Ist-Mengen) über Reload/Absturz hinweg erhalten bleiben
müssen. Der Service Worker selbst cached nur den App-Shell (Assets), keine API-Requests.
- **Idempotenz**: `PUT /kontrollen/{id}/positionen/{material_id}` ist backend-seitig ein
Upsert (siehe `backend/app/services/kontrolle.py`) - die Queue kann denselben Eintrag
beliebig oft erneut senden, ohne doppelte Kontrollpositionen/Fehlbestände zu erzeugen.
- **Statusanzeige**: jede Position zeigt "nicht gespeichert" / "wird übertragen…" /
"gespeichert" / "Fehler" - kein stiller Datenverlust bei Verbindungsabbruch (Prompt 17.5).
- **Abschluss-Sperre**: der Abschließen-Button ist deaktiviert, solange auch nur eine
Position nicht bestätigt gespeichert ist.
- Client-Fehler (4xx, z. B. Objekt-Sperre durch Übernahme) werden NICHT automatisch
wiederholt - der Mitarbeiter sieht den Fehler und muss bewusst reagieren.
## E2E-Tests (Playwright)
```bash
npm install
npx playwright install chromium
npm run test:e2e
```
Läuft komplett gegen einen gemockten Backend (`e2e/mockApi.ts`, `page.route`) - kein
echtes Backend/DB nötig, `playwright.config.ts` startet `npm run dev` automatisch.
Deckt Login, Objekt-Sperre/Übernahme, Fortschrittsanzeige und die Offline-Queue
(Reconnect-Verhalten) ab. Reale Integrationstests gegen ein echtes Backend sowie die
Praktiker-Explorations-Session (Testphase 4) sind ein separater, späterer Schritt -
dafür wird ein laufendes Test-Deployment gebraucht, kein reiner Code-Schritt.