README: Ausblick durch den tatsaechlichen Stand ersetzt

Alle 15 Typen sind gebaut — der Abschnitt beschrieb noch die Planung. Statt
dessen: wie ein weiterer Typ dazukommt, und was als Naechstes sinnvoll waere.
This commit is contained in:
Florian Wilde
2026-08-15 00:33:18 +02:00
parent e4ff55a6c9
commit 055d8caaa0
+31 -17
View File
@@ -30,7 +30,7 @@ entscheidet die Verwaltung — nicht gebrauchte lassen sich ausblenden.
- [Technischer Aufbau](#technischer-aufbau) - [Technischer Aufbau](#technischer-aufbau)
- [Entwicklung ohne Docker](#entwicklung-ohne-docker) - [Entwicklung ohne Docker](#entwicklung-ohne-docker)
- [API](#api) - [API](#api)
- [Ausblick Version 2](#ausblick-version-2) - [Einen weiteren Typ ergänzen](#einen-weiteren-typ-ergänzen)
--- ---
@@ -860,25 +860,39 @@ curl -X POST http://localhost:3000/api/codes \
--- ---
## Ausblick Version 2 ## Einen weiteren Typ ergänzen
Geplant sind die übrigen 14 Typen: vCard, App-Link, Mehrere Links, Social Alle 15 vorgesehenen Typen sind gebaut. Kommt ein sechzehnter dazu, besteht er
Media, WhatsApp, PDF, Bild, Video, E-Mail, SMS, Standort, Zahlung, WLAN und aus:
Feedback.
Die Architektur ist darauf ausgelegt — ein neuer Typ besteht aus:
1. **einem Modul** in `src/lib/qr/types/` (Zod-Schema, Kodierung, Kurzfassung), 1. **einem Modul** in `src/lib/qr/types/` (Zod-Schema, Kodierung, Kurzfassung),
2. **einer Formular-Komponente** in `src/components/qr-forms/`, 2. **einer Formular-Komponente** in `src/components/qr-forms/`,
3. **je einem Eintrag** in `src/lib/qr/registry.ts` (ersetzt dort den 3. **je einem Eintrag** in `src/lib/qr/registry.ts` und in
`defineComingSoonType`-Platzhalter) und in `src/components/qr-forms/index.ts`,
`src/components/qr-forms/index.ts`. 4. **einer Landingpage** in `src/components/landing/`, falls er `hasLandingPage`
meldet.
Am bestehenden Code aus Version 1 ist dafür nichts zu ändern: Vorschau, Am übrigen Code ist dafür nichts zu ändern: Vorschau, Download, Gestaltung,
Download, Gestaltung, Speicherung dynamischer Codes und die Weiterleitung Speicherung, Weiterleitung, Liste und Verwaltung arbeiten für alle Typen
arbeiten für alle Typen gleich. gleich. Die Kennung gehört zusätzlich in `QR_TYPE_IDS` in
`src/lib/qr/type-module.ts`.
Typen, die statt einer Weiterleitung eine eigene Landingpage brauchen (etwa Für einen angekündigten, aber noch nicht gebauten Typ gibt es
„Mehrere Links“ oder „Feedback“), setzen dafür `redirectTarget` auf eine `defineComingSoonType`: Er erscheint als Kachel mit dem Badge „Bald
interne Adresse — auch dafür ist keine Änderung am Datenmodell nötig, weil verfügbar“ und lässt sich nicht öffnen.
`data` als JSONB gespeichert wird.
Braucht der Typ eine hochgeladene Datei, meldet er ihre Ids über `uploadIds` —
daran hängt, was beim Löschen des Codes mitgeht und was als verwaist
weggeräumt wird.
### Was als Nächstes sinnvoll wäre
- **Gruppen aus dem Verzeichnis übernehmen.** Die OIDC-Anbindung übernimmt
heute bewusst nur die Identität. Eine Zuordnung von Verzeichnisgruppen zu
Gruppen dieser Anwendung wäre möglich, braucht aber eine klare Regel dafür,
was mit von Hand vergebenen Rollen passiert.
- **Statistik über die Zeit.** Der Zähler weiß heute nur, wie oft und wann
zuletzt. Ein Verlauf je Tag wäre eine eigene Tabelle — und die Frage, wie
lange man ihn aufbewahrt.
- **Codes exportieren.** Eine CSV aller Codes einer Gruppe, für die Übergabe
an Druckereien.