Sascha WolfandClaude Opus 5
87759a8a24
Neben dem Design des Hauses ("perinco") gibt es "Pixel Art" und
"Outdoor", jedes in hell und dunkel. Die Wahl steht neben dem
Hell/Dunkel-Schalter im Kopf der App.
Sie gehoert dem BENUTZER und nicht dem Browser: crm_users.theme und
crm_users.theme_mode, gesetzt ueber PATCH /api/auth/me, das jeder fuer
sich selbst darf. Wer sich an einem anderen Rechner anmeldet, findet sein
Design wieder, und zwei Benutzer an derselben Maschine kommen sich nicht
in die Quere. Der localStorage bleibt als Zwischenspeicher daneben, damit
das Inline-Skript in index.html die Klassen vor dem ersten Frame setzen
kann - ohne das blitzt beim Laden das Standarddesign auf. Das hat eine
sichtbare Folge: melden sich zwei Leute an demselben Rechner an, sieht
der zweite fuer einen Augenblick das Design des ersten.
Der ThemeProvider steht deshalb in main.tsx jetzt unter dem AuthProvider
- er liest den Benutzer.
Keine Komponente wurde umgefaerbt. Im Markup steht nirgends eine feste
Farbe, sondern durchgaengig ink-*, brand-*, canvas und surface; Tailwind
v4 loest auch --radius-*, --shadow-* und die Schriften ueber Variablen
auf. Ein Theme tauscht also nur Werte, und deshalb kann Pixel Art alle
380 abgerundeten Ecken eckig machen, ohne eine Klasse anzufassen.
Zwei Dinge waren Voraussetzung:
- Der helle Block eines Themes braucht :not(.dark). html.theme-x hat
eine Klasse mehr in der Spezifitaet als .dark und wuerde den
Dunkelmodus sonst ueberstimmen.
- Auf brand-500/600 steht 69 Mal weisse Schrift. Jedes Theme braucht
dort einen ausreichend dunklen Ton - ein helles Pastell waere
unlesbar.
Die Pixelschrift (Silkscreen) sitzt nur in --font-display, also in den
Ueberschriften und den Feldbeschriftungen; labelClass tragt dafuer die
neue Klasse "field-label". Der Fliesstext bleibt Nunito Sans: die Listen
haben bis zu acht Spalten bei 11-13 px, und eine Pixelschrift waere darin
nicht mehr zu lesen. Outdoor bringt Cabin fuer beides mit.
server/test/userFields.test.mjs prueft die Werte und dass die Liste der
Farbwelten in userFields.js und src/types.ts nicht auseinanderlaeuft -
sonst zeigt die Auswahl ein Design an, dessen Speichern das Backend
abweist, und niemand weiss warum.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
34 lines
1.1 KiB
TypeScript
34 lines
1.1 KiB
TypeScript
import React from 'react';
|
|
import { createRoot } from 'react-dom/client';
|
|
import './index.css';
|
|
import App from './App';
|
|
import { ToastProvider } from './components/Toast';
|
|
import { AuthProvider } from './lib/auth';
|
|
import { ThemeProvider } from './lib/theme';
|
|
import { WhisperProvider } from './lib/whisper';
|
|
|
|
const container = document.getElementById('root');
|
|
if (!container) throw new Error('Root-Element #root nicht gefunden.');
|
|
|
|
/*
|
|
* Die Reihenfolge ist keine Geschmacksfrage: der ThemeProvider steht **unter**
|
|
* dem AuthProvider, weil das Design am Benutzer haengt und er ihn dafuer lesen
|
|
* muss (crm_users.theme). Bis jemand angemeldet ist - also auf dem
|
|
* Anmeldebildschirm - gilt der Zwischenspeicher aus dem localStorage, den auch
|
|
* das Inline-Skript in index.html benutzt.
|
|
*/
|
|
createRoot(container).render(
|
|
<React.StrictMode>
|
|
<ToastProvider>
|
|
<AuthProvider>
|
|
<ThemeProvider>
|
|
{/* Haelt Modelleinstellungen und den Whisper-Worker */}
|
|
<WhisperProvider>
|
|
<App />
|
|
</WhisperProvider>
|
|
</ThemeProvider>
|
|
</AuthProvider>
|
|
</ToastProvider>
|
|
</React.StrictMode>
|
|
);
|