dejanandClaude Opus 5
99be627dad
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
61 lines
2.1 KiB
TypeScript
61 lines
2.1 KiB
TypeScript
/**
|
|
* View-Model der Finanzseite.
|
|
*
|
|
* 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 {
|
|
marge,
|
|
offeneNachStatus,
|
|
offenePosten,
|
|
umsatz,
|
|
umsatzNachGewerk,
|
|
umsatzVerlauf,
|
|
umsatzVorperiode,
|
|
zahlungsdauer,
|
|
type OffenePosten,
|
|
} from "../data/calculations";
|
|
import type { ChartPunkt, Datensatz, FilterState, ZeitreihePunkt } from "../data/types";
|
|
import { bereit, leer, type VMState } from "./index";
|
|
|
|
export interface FinanzenDaten {
|
|
readonly umsatzAktuell: number;
|
|
readonly umsatzVorher: number;
|
|
readonly verlauf: ZeitreihePunkt[];
|
|
readonly sparkline: number[];
|
|
readonly posten: OffenePosten;
|
|
readonly zahlungsdauerTage: number;
|
|
readonly margeProzent: number;
|
|
readonly offenNachStatus: ChartPunkt[];
|
|
readonly gewerkUmsatz: ChartPunkt[];
|
|
/**
|
|
* Kundenname je Id. Die Rechnung trägt nur die Id; die Auflösung gehört zu den
|
|
* Daten, nicht in die Zellen-Funktion der Tabelle.
|
|
*/
|
|
readonly kundeName: ReadonlyMap<string, string>;
|
|
}
|
|
|
|
export function baueFinanzenVM(daten: Datensatz, filter: FilterState): VMState<FinanzenDaten> {
|
|
// Kein Auftrag und keine Rechnung heisst: Die Filter schneiden alles weg.
|
|
// Das ist ein Leerzustand, kein Fehler.
|
|
if (!daten.auftraege.length && !daten.rechnungen.length) return leer();
|
|
|
|
const verlauf = umsatzVerlauf(daten.rechnungen, filter.zeitraum);
|
|
|
|
return bereit({
|
|
umsatzAktuell: umsatz(daten.rechnungen, filter.zeitraum),
|
|
umsatzVorher: umsatzVorperiode(daten.rechnungen, filter.zeitraum),
|
|
verlauf,
|
|
sparkline: verlauf.slice(-10).map((p) => p.value),
|
|
posten: offenePosten(daten.rechnungen),
|
|
zahlungsdauerTage: zahlungsdauer(daten.rechnungen, filter.zeitraum),
|
|
margeProzent: marge(daten.auftraege, filter.zeitraum),
|
|
offenNachStatus: offeneNachStatus(daten.rechnungen),
|
|
gewerkUmsatz: umsatzNachGewerk(daten.auftraege, daten.rechnungen, filter.zeitraum),
|
|
kundeName: new Map(daten.kunden.map((k) => [k.id, k.name])),
|
|
});
|
|
}
|