Files
Dashboard/features/dashboard/view-models/kunden.vm.ts
T
dejanandClaude Opus 5 99be627dad refactor(dashboard): Seiten von der Datenquelle entkoppeln
Die Seiten holten ihre Zahlen selbst aus einem globalen Store. HiveGrid Cloud
verlangt reine Screens nach dem Muster <XPage vm={} actions={} /> — jede Seite
hätte beim Einbau auseinandergenommen werden müssen.

Neue Schichtung:

  view-models/<seite>.vm.ts   baue<Seite>VM(daten, filter) → VMState<…>
                              reine Funktion, kein React, kein Store
  pages/<Seite>.tsx           ({ vm, optionen }) → JSX      wird portiert
  routes/<Seite>Route.tsx     Store + Builder + Seite       wird ersetzt

view-models/index.ts spiegelt VMState wortgleich aus @hivegrid/view-models;
beim Einbau ist es ein Import-Wechsel. Der Loader ruft denselben Builder mit
echten Daten, die Seiten bleiben unberührt.

Dabei abgefallen: die fünf Seitenzustände (idle · loading · ready · empty ·
error) über SeitenZustand — bisher lief der Prototyp nur im Zustand "Daten da",
in der Cloud sind alle fünf DoD-Pflicht. Die Filterleiste bekommt ihre
Auswahllisten jetzt als Prop (in der Software die Facetten aus dem Loader)
statt sie selbst aus dem Datensatz zu ziehen.

Store- und Rohdatenzugriff gibt es damit ausschließlich in routes/. Alle sechs
Seiten rendern pixelgleich; typecheck, lint und build sind grün.

Nicht geändert: Next.js bleibt. Im gesamten Projekt gibt es vier
Next-spezifische Importe, alle in AppShell und app/layout — beide Dateien
entfallen beim Einbau ohnehin, weil die Cloud Shell und Root-Layout mitbringt.
Ein Framework-Wechsel wäre Aufwand ohne Ertrag.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QPeZNwSeU7qG3RRCwaxEZX
2026-08-29 17:39:41 +02:00

67 lines
2.3 KiB
TypeScript

/**
* View-Model der Kundenseite.
*
* Reine Funktion über typisierten Eingangsdaten — kein React, kein Store, kein
* Zugriff auf `DATENSATZ`. Genau diese Grenze macht den Einbau billig: In der
* Software ruft der Loader denselben Builder mit echten Daten auf, die
* Screen-Komponente bleibt unverändert.
*/
import {
inaktiveKunden,
kundenEntwicklung,
kundenNach,
neueKunden,
neueKundenVorperiode,
topKunden,
wiederkehrquote,
zahlungsauffaellig,
} from "../data/calculations";
import type { ChartPunkt, Datensatz, FilterState, Kunde, ZeitreihePunkt } from "../data/types";
import { bereit, leer, type VMState } from "./index";
export interface KundenDaten {
readonly kundenGesamt: number;
readonly kundenMitAuftrag: number;
readonly neueKunden: number;
readonly neueKundenVorher: number;
readonly entwicklung: ZeitreihePunkt[];
readonly sparkline: number[];
readonly wiederkehrendProzent: number;
readonly kundenwert: number;
readonly inaktive: Kunde[];
readonly auffaellige: Kunde[];
readonly nachQuelle: ChartPunkt[];
readonly nachTyp: ChartPunkt[];
readonly topKunden: ChartPunkt[];
}
export function baueKundenVM(daten: Datensatz, filter: FilterState): VMState<KundenDaten> {
// Kein Kunde in der Auswahl heisst: Die Filter schneiden alles weg.
// Das ist ein Leerzustand, kein Fehler.
if (!daten.kunden.length) return leer();
const entwicklung = kundenEntwicklung(daten.kunden, filter.zeitraum);
const mitAuftrag = daten.kunden.filter((k) => k.auftraegeGesamt > 0);
return bereit({
kundenGesamt: daten.kunden.length,
kundenMitAuftrag: mitAuftrag.length,
neueKunden: neueKunden(daten.kunden, filter.zeitraum),
neueKundenVorher: neueKundenVorperiode(daten.kunden, filter.zeitraum),
entwicklung,
sparkline: entwicklung.slice(-10).map((p) => p.value),
wiederkehrendProzent: wiederkehrquote(daten.kunden),
// Bezugsgrösse ist der Kunde mit Historie — Karteileichen würden den
// Durchschnitt nach unten ziehen.
kundenwert: mitAuftrag.length
? mitAuftrag.reduce((s, k) => s + k.umsatzGesamt, 0) / mitAuftrag.length
: 0,
inaktive: inaktiveKunden(daten.kunden),
auffaellige: zahlungsauffaellig(daten.kunden),
nachQuelle: kundenNach(daten.kunden, "quelle"),
nachTyp: kundenNach(daten.kunden, "typ"),
topKunden: topKunden(daten.kunden, 6),
});
}