Optionaler Darkmode ist aktuell im Trend, somit müssen wir diese Optik auch anbieten können.
Darkmode soll einstellbar sein und anschließend beim Nutzer gespeichert werden, sodas beim Relogin der zuletzt gewählte optische Modus wieder aktiviert wird.
Optionaler Darkmode ist aktuell im Trend, somit müssen wir diese Optik auch anbieten können.
Darkmode soll einstellbar sein und anschließend beim Nutzer gespeichert werden, sodas beim Relogin der zuletzt gewählte optische Modus wieder aktiviert wird.
next-themes (war bereits als Dependency vorhanden, aber nie verdrahtet) jetzt aktiv über einen ThemeProvider im Root-Layout; die komplette Token-Infrastruktur dafür (:root/.dark-Blöcke in globals.css) existierte ebenfalls schon fertig
Toggle-Platzierung:
Eingeloggter Bereich: Switch in der Desktop-Sidebar (neben der Sprachauswahl) + Eintrag im Mobile-Pet-Switcher-Dropdown
Öffentliche Landingpage: eigener Sonne/Mond-Button in der Navbar für Besucher ohne Account (rein browserlokal via localStorage, kein Owner-Bezug möglich mangels Login)
Clerk-Theming:@clerk/themes ergänzt, neuer ClerkThemeProvider-Wrapper schaltet Clerks eigenes UI (z. B. UserButton-Dropdown) synchron mit auf Dark — sonst hätte das als helles Popup auf dunklem Hintergrund gewirkt.
Nachgebesserter Bug (User-Feedback nach Deploy): die drei schwebenden Badges im Hero-Phone-Mockup ("Neuer Beitrag von Bubi" / "Likes, Follows, Reaktionen" / "Story ist aktiv") hatten hartcodiert weißen Chip-Hintergrund, aber Text über das text-foreground-Token — das kippte im Dark Mode auf helles Grau und war auf dem weiterhin weißen Chip kaum lesbar. Fest auf dunklen Text gesetzt, da der Chip-Hintergrund bewusst immer weiß bleibt.
tsc/Vitest/Build sauber, Docker-Build erfolgreich, live auf pawfeed.org verifiziert (Toggle-Funktion, Landingpage in Light+Dark, Badge-Kontrast).
## Dark Mode umgesetzt (Commits `d670cf9`, `d21f470`, `2b52345`, deployed)
**Persistenz account-gebunden** (nicht nur localStorage), damit die Wahl wie gewünscht beim Relogin auf jedem Gerät wieder aktiv ist:
- Neues `Owner.themePreference`-Feld (Enum `LIGHT`/`DARK`, nullable = folgt Systemeinstellung, solange nie manuell umgeschaltet wurde)
- Neuer `owner.ts`-tRPC-Router (`getThemePreference`/`setThemePreference`), 5 Vitest-Tests
- `next-themes` (war bereits als Dependency vorhanden, aber nie verdrahtet) jetzt aktiv über einen `ThemeProvider` im Root-Layout; die komplette Token-Infrastruktur dafür (`:root`/`.dark`-Blöcke in `globals.css`) existierte ebenfalls schon fertig
**Toggle-Platzierung:**
- Eingeloggter Bereich: Switch in der Desktop-Sidebar (neben der Sprachauswahl) + Eintrag im Mobile-Pet-Switcher-Dropdown
- Öffentliche Landingpage: eigener Sonne/Mond-Button in der Navbar für Besucher ohne Account (rein browserlokal via localStorage, kein Owner-Bezug möglich mangels Login)
**Clerk-Theming:** `@clerk/themes` ergänzt, neuer `ClerkThemeProvider`-Wrapper schaltet Clerks eigenes UI (z. B. UserButton-Dropdown) synchron mit auf Dark — sonst hätte das als helles Popup auf dunklem Hintergrund gewirkt.
**Nachgebesserter Bug (User-Feedback nach Deploy):** die drei schwebenden Badges im Hero-Phone-Mockup ("Neuer Beitrag von Bubi" / "Likes, Follows, Reaktionen" / "Story ist aktiv") hatten hartcodiert weißen Chip-Hintergrund, aber Text über das text-foreground-Token — das kippte im Dark Mode auf helles Grau und war auf dem weiterhin weißen Chip kaum lesbar. Fest auf dunklen Text gesetzt, da der Chip-Hintergrund bewusst immer weiß bleibt.
tsc/Vitest/Build sauber, Docker-Build erfolgreich, live auf pawfeed.org verifiziert (Toggle-Funktion, Landingpage in Light+Dark, Badge-Kontrast).
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Optionaler Darkmode ist aktuell im Trend, somit müssen wir diese Optik auch anbieten können.
Darkmode soll einstellbar sein und anschließend beim Nutzer gespeichert werden, sodas beim Relogin der zuletzt gewählte optische Modus wieder aktiviert wird.
Dark Mode umgesetzt (Commits
d670cf9,d21f470,2b52345, deployed)Persistenz account-gebunden (nicht nur localStorage), damit die Wahl wie gewünscht beim Relogin auf jedem Gerät wieder aktiv ist:
Owner.themePreference-Feld (EnumLIGHT/DARK, nullable = folgt Systemeinstellung, solange nie manuell umgeschaltet wurde)owner.ts-tRPC-Router (getThemePreference/setThemePreference), 5 Vitest-Testsnext-themes(war bereits als Dependency vorhanden, aber nie verdrahtet) jetzt aktiv über einenThemeProviderim Root-Layout; die komplette Token-Infrastruktur dafür (:root/.dark-Blöcke inglobals.css) existierte ebenfalls schon fertigToggle-Platzierung:
Clerk-Theming:
@clerk/themesergänzt, neuerClerkThemeProvider-Wrapper schaltet Clerks eigenes UI (z. B. UserButton-Dropdown) synchron mit auf Dark — sonst hätte das als helles Popup auf dunklem Hintergrund gewirkt.Nachgebesserter Bug (User-Feedback nach Deploy): die drei schwebenden Badges im Hero-Phone-Mockup ("Neuer Beitrag von Bubi" / "Likes, Follows, Reaktionen" / "Story ist aktiv") hatten hartcodiert weißen Chip-Hintergrund, aber Text über das text-foreground-Token — das kippte im Dark Mode auf helles Grau und war auf dem weiterhin weißen Chip kaum lesbar. Fest auf dunklen Text gesetzt, da der Chip-Hintergrund bewusst immer weiß bleibt.
tsc/Vitest/Build sauber, Docker-Build erfolgreich, live auf pawfeed.org verifiziert (Toggle-Funktion, Landingpage in Light+Dark, Badge-Kontrast).