{"id":326,"date":"2026-09-05T18:21:37","date_gmt":"2026-09-05T18:21:37","guid":{"rendered":"https:\/\/www.fabricioruch.ch\/?p=326"},"modified":"2026-09-05T18:21:37","modified_gmt":"2026-09-05T18:21:37","slug":"erst-die-zustandsmaschine-dann-der-spinner","status":"publish","type":"post","link":"https:\/\/www.fabricioruch.ch\/?p=326","title":{"rendered":"Erst die Zustandsmaschine, dann der Spinner"},"content":{"rendered":"\n

Bei Terminalanwendungen beginnt die Arbeit oft an der falschen Stelle.<\/p>\n\n\n\n

Man hat eine Idee f\u00fcr ein Tool, baut die eigentliche Funktion und m\u00f6chte dann schnell etwas Feedback im Terminal anzeigen.<\/p>\n\n\n\n

Also kommt zuerst:<\/p>\n\n\n\n

Connecting...\n<\/code><\/pre>\n\n\n\n
Dann:<\/p>\n\n\n\n
Processing...\n<\/code><\/pre>\n\n\n\n
Dann ein Spinner.<\/p>\n\n\n\n
Dann Farben.<\/p>\n\n\n\n
Dann eine Progressbar.<\/p>\n\n\n\n
Dann ein Banner.<\/p>\n\n\n\n
Dann \u00dcberg\u00e4nge.<\/p>\n\n\n\n
Dann ein finaler Erfolgs-Screen.<\/p>\n\n\n\n
Das Ergebnis sieht irgendwann gut aus.<\/p>\n\n\n\n
Und trotzdem f\u00fchlt sich der Code merkw\u00fcrdig fragil an.<\/p>\n\n\n\n
Der Grund liegt h\u00e4ufig darin, dass die Darstellung gebaut wurde, bevor \u00fcberhaupt klar war, welche Zust\u00e4nde die Anwendung besitzt<\/strong>.<\/p>\n\n\n\n
Das ist die falsche Reihenfolge.<\/p>\n\n\n\n
Eine gute TUI beginnt nicht mit dem Spinner.<\/p>\n\n\n\n
Sie beginnt mit der Zustandsmaschine.<\/p>\n\n\n\n
\n\n\n\n
Ein Spinner ist nur ein Symptom eines Zustands<\/h2>\n\n\n\n
Ein Spinner zeigt nicht einfach \u201eAnimation\u201c.<\/p>\n\n\n\n
Er transportiert eine Information:<\/p>\n\n\n\n
\n
Die Anwendung arbeitet gerade, aber der Fortschritt ist nicht exakt messbar.<\/p>\n<\/blockquote>\n\n\n\n
Das ist bereits ein Zustand.<\/p>\n\n\n\n
Wenn dort steht:<\/p>\n\n\n\n
\u2839 Connecting...\n<\/code><\/pre>\n\n\n\n
dann steckt dahinter semantisch:<\/p>\n\n\n\n
State = Connecting\n<\/code><\/pre>\n\n\n\n
Wenn dort steht:<\/p>\n\n\n\n
\u2588\u2588\u2588\u2588\u2588\u2588\u2588\u2588\u2588\u2588\u2588\u2588\u2588\u2588\u2588\u2588\u2588\u2588\u2591\u2591\u2591\u2591 72%\n<\/code><\/pre>\n\n\n\n
dann steckt dahinter eher:<\/p>\n\n\n\n
State = Processing\nProgress = 72%\n<\/code><\/pre>\n\n\n\n
Und wenn sp\u00e4ter erscheint:<\/p>\n\n\n\n
VERIFICATION SUCCESSFUL\n<\/code><\/pre>\n\n\n\n
dann ist auch das kein dekorativer Screen.<\/p>\n\n\n\n
Es ist die Darstellung eines anderen Zustands.<\/p>\n\n\n\n
Die TUI ist deshalb nicht die Quelle der Wahrheit.<\/p>\n\n\n\n
Sie ist nur die Visualisierung eines bereits existierenden Zustandsmodells.<\/p>\n\n\n\n
\n\n\n\n
Was ist \u00fcberhaupt eine Zustandsmaschine?<\/h1>\n\n\n\n
Eine Zustandsmaschine beschreibt, in welchem Zustand sich ein System befindet und welche \u00dcberg\u00e4nge zwischen diesen Zust\u00e4nden erlaubt sind.<\/p>\n\n\n\n
F\u00fcr ein einfaches Werkzeug k\u00f6nnte das so aussehen:<\/p>\n\n\n\n
START\n  \u2193\nCONNECTING\n  \u2193\nPROCESSING\n  \u2193\nCOMPLETED\n<\/code><\/pre>\n\n\n\n
Das klingt zun\u00e4chst fast trivial.<\/p>\n\n\n\n
Sobald reale Fehlerf\u00e4lle dazukommen, wird es interessanter:<\/p>\n\n\n\n
START\n  \u2193\nCONNECTING\n  \u251c\u2500\u2500\u2192 FAILED\n  \u2193\nREADY\n  \u2193\nPROCESSING\n  \u251c\u2500\u2500\u2192 RETRYING\n  \u2502       \u2193\n  \u2502    PROCESSING\n  \u2502\n  \u251c\u2500\u2500\u2192 FAILED\n  \u2193\nVERIFYING\n  \u251c\u2500\u2500\u2192 FAILED\n  \u2193\nCOMPLETED\n<\/code><\/pre>\n\n\n\n
Pl\u00f6tzlich wird sichtbar:<\/p>\n\n\n\n
Das Programm besteht nicht nur aus einer Reihe von Funktionen.<\/p>\n\n\n\n
Es bewegt sich durch definierte Zust\u00e4nde.<\/p>\n\n\n\n
\n\n\n\n
Implizite Zust\u00e4nde entstehen sowieso<\/h1>\n\n\n\n
Viele Skripte besitzen bereits Zust\u00e4nde, obwohl sie nie so genannt werden.<\/p>\n\n\n\n
Zum Beispiel:<\/p>\n\n\n\n
$connected = $false\n$processing = $false\n$completed = $false\n$failed = $false\n<\/code><\/pre>\n\n\n\n
Dann sp\u00e4ter:<\/p>\n\n\n\n
$connected = $true\n$processing = $true\n<\/code><\/pre>\n\n\n\n
und irgendwann:<\/p>\n\n\n\n
$processing = $false\n$completed = $true\n<\/code><\/pre>\n\n\n\n
Damit wurde bereits eine Zustandsmaschine gebaut.<\/p>\n\n\n\n
Nur eine schlechte.<\/p>\n\n\n\n
Denn theoretisch w\u00e4ren jetzt auch Kombinationen m\u00f6glich wie:<\/p>\n\n\n\n
connected = false\nprocessing = true\ncompleted = true\nfailed = true\n<\/code><\/pre>\n\n\n\n
Was soll das bedeuten?<\/p>\n\n\n\n
Mit mehreren Booleans w\u00e4chst die Zahl m\u00f6glicher Kombinationen extrem schnell.<\/p>\n\n\n\n
Vier Boolean-Werte haben bereits:<\/p>\n\n\n\n
2\u2074 = 16\n<\/code><\/pre>\n\n\n\n
m\u00f6gliche Kombinationen.<\/p>\n\n\n\n
Aber vermutlich sind nur wenige davon tats\u00e4chlich g\u00fcltig.<\/p>\n\n\n\n
Ein expliziter State ist deshalb besser:<\/p>\n\n\n\n
$state = 'Processing'\n<\/code><\/pre>\n\n\n\n
Statt:<\/p>\n\n\n\n
$isConnected = $true\n$isProcessing = $true\n$isCompleted = $false\n$isFailed = $false\n<\/code><\/pre>\n\n\n\n
\n\n\n\n
Ein Zustand sollte eindeutig sein<\/h1>\n\n\n\n
Eine Anwendung sollte zu einem Zeitpunkt m\u00f6glichst klar beantworten k\u00f6nnen:<\/p>\n\n\n\n
\n
Was mache ich gerade?<\/p>\n<\/blockquote>\n\n\n\n
Zum Beispiel:<\/p>\n\n\n\n
Initializing\nConnecting\nAuditing\nWaitingForConfirmation\nProcessing\nRetrying\nVerifying\nCompleted\nFailed\nCancelled\n<\/code><\/pre>\n\n\n\n
Diese Zust\u00e4nde schlie\u00dfen sich weitgehend gegenseitig aus.<\/p>\n\n\n\n
Das reduziert Ambiguit\u00e4t.<\/p>\n\n\n\n
Die TUI kann darauf direkt reagieren.<\/p>\n\n\n\n
switch ($State.Phase) {\n    'Connecting' {\n        Show-ConnectingScreen\n    }\n\n    'Processing' {\n        Show-ProcessingScreen\n    }\n\n    'Verifying' {\n        Show-VerificationScreen\n    }\n\n    'Completed' {\n        Show-CompletedScreen\n    }\n}\n<\/code><\/pre>\n\n\n\n
Damit wird die Oberfl\u00e4che deterministisch.<\/p>\n\n\n\n
\n\n\n\n
Der Zustand ist mehr als ein Name<\/h1>\n\n\n\n
Nur:<\/p>\n\n\n\n
$State = 'Processing'\n<\/code><\/pre>\n\n\n\n
reicht meist nicht.<\/p>\n\n\n\n
Ein Zustand braucht Kontext.<\/p>\n\n\n\n
Beispielsweise:<\/p>\n\n\n\n
$state = [pscustomobject]@{\n    Phase         = 'Processing'\n    CurrentFolder = 'Archive \/ 2025'\n    Processed     = 116\n    Total         = 184\n    Failed        = 0\n    StartedAt     = $startedAt\n}\n<\/code><\/pre>\n\n\n\n
Die TUI kann daraus alles ableiten, was sie braucht.<\/p>\n\n\n\n
Zum Beispiel:<\/p>\n\n\n\n
PROCESSING\n\nArchive \/ 2025\n\n\u2588\u2588\u2588\u2588\u2588\u2588\u2588\u2588\u2588\u2588\u2588\u2588\u2588\u2588\u2588\u2588\u2588\u2588\u2588\u2588\u2588\u2588\u2588\u2588\u2591\u2591\u2591\u2591\u2591\u2591\u2591\u2591 63%\n\n116 processed\n 68 remaining\n  0 failed\n<\/code><\/pre>\n\n\n\n
Der Renderer muss nichts \u00fcber die Gesch\u00e4ftslogik wissen.<\/p>\n\n\n\n
Er bekommt nur State.<\/p>\n\n\n\n
\n\n\n\n
State und Event sind nicht dasselbe<\/h1>\n\n\n\n
Das ist eine wichtige Unterscheidung.<\/p>\n\n\n\n
Ein Event beschreibt:<\/p>\n\n\n\n
\n
Etwas ist gerade passiert.<\/p>\n<\/blockquote>\n\n\n\n
Ein State beschreibt:<\/p>\n\n\n\n
\n
So sieht die Situation jetzt aus.<\/p>\n<\/blockquote>\n\n\n\n
Beispiel:<\/p>\n\n\n\n
Event:\nMessageProcessed\n<\/code><\/pre>\n\n\n\n
Danach kann der Zustand sein:<\/p>\n\n\n\n
Processed = 117\nRemaining = 67\n<\/code><\/pre>\n\n\n\n
Oder:<\/p>\n\n\n\n
Event:\nRetryScheduled\n<\/code><\/pre>\n\n\n\n
Danach:<\/p>\n\n\n\n
Phase = Retrying\nRetryCount = 2\nRetryAfter = 5\n<\/code><\/pre>\n\n\n\n
Events sind punktuell.<\/p>\n\n\n\n
State ist persistent.<\/p>\n\n\n\n
Das ist besonders f\u00fcr TUIs wichtig, weil ein Screen jederzeit aus dem aktuellen Zustand neu aufgebaut werden k\u00f6nnen sollte.<\/p>\n\n\n\n
\n\n\n\n
Gute TUIs rendern State, nicht Event-Historie<\/h1>\n\n\n\n
Schlecht w\u00e4re:<\/p>\n\n\n\n
Connected\nFolder found\nMessage processed\nMessage processed\nMessage processed\nRetry\nMessage processed\n...\n<\/code><\/pre>\n\n\n\n
Das ist Log-Ausgabe.<\/p>\n\n\n\n
Eine TUI sollte eher den aktuellen Zustand verdichten:<\/p>\n\n\n\n
PROCESSING\n\nCurrent folder\nArchive \/ 2025\n\nProcessed   117\nRemaining    67\nRetries       1\nFailed        0\n<\/code><\/pre>\n\n\n\n
Logs beantworten:<\/p>\n\n\n\n
\n
Was ist alles passiert?<\/p>\n<\/blockquote>\n\n\n\n
Eine TUI beantwortet:<\/p>\n\n\n\n
\n
Wo stehen wir jetzt?<\/p>\n<\/blockquote>\n\n\n\n
Diese Trennung ist zentral.<\/p>\n\n\n\n
\n\n\n\n
Ein Screen ist eine Projektion des Zustands<\/h1>\n\n\n\n
Ein Screen sollte nicht selbst entscheiden, wie die Anwendung weiterl\u00e4uft.<\/p>\n\n\n\n
Er stellt nur State dar.<\/p>\n\n\n\n
Zum Beispiel:<\/p>\n\n\n\n
State\n\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\nPhase = Processing\nProcessed = 117\nTotal = 184\nFailed = 0\n<\/code><\/pre>\n\n\n\n
wird projiziert auf:<\/p>\n\n\n\n
PROCESSING\n\n\u2588\u2588\u2588\u2588\u2588\u2588\u2588\u2588\u2588\u2588\u2588\u2588\u2588\u2588\u2588\u2588\u2588\u2588\u2588\u2588\u2588\u2588\u2588\u2588\u2588\u2591\u2591\u2591\u2591\u2591 64%\n\n117 \/ 184\n\n0 failed\n<\/code><\/pre>\n\n\n\n
Man k\u00f6nnte denselben State aber auch als JSON darstellen:<\/p>\n\n\n\n
{\n  \"phase\": \"processing\",\n  \"processed\": 117,\n  \"total\": 184,\n  \"failed\": 0\n}\n<\/code><\/pre>\n\n\n\n
Oder als Log:<\/p>\n\n\n\n
2026-09-05T14:32:10Z processed=117 total=184 failed=0\n<\/code><\/pre>\n\n\n\n
Das zeigt den Vorteil:<\/p>\n\n\n\n
State\n  \u251c\u2500\u2500 TUI\n  \u251c\u2500\u2500 JSON\n  \u2514\u2500\u2500 Log\n<\/code><\/pre>\n\n\n\n
Die Engine bleibt dieselbe.<\/p>\n\n\n\n
\n\n\n\n
Zustands\u00fcberg\u00e4nge m\u00fcssen bewusst definiert sein<\/h1>\n\n\n\n
Wenn Zust\u00e4nde explizit werden, sollte auch klar sein, welche \u00dcberg\u00e4nge erlaubt sind.<\/p>\n\n\n\n
Zum Beispiel:<\/p>\n\n\n\n
Initializing\n    \u2193\nConnecting\n    \u2193\nAuditing\n    \u2193\nWaitingForConfirmation\n    \u2193\nProcessing\n    \u2193\nVerifying\n    \u2193\nCompleted\n<\/code><\/pre>\n\n\n\n
Ein \u00dcbergang:<\/p>\n\n\n\n
Completed \u2192 Processing\n<\/code><\/pre>\n\n\n\n
w\u00e4re dagegen wahrscheinlich ung\u00fcltig.<\/p>\n\n\n\n
Oder:<\/p>\n\n\n\n
Connecting \u2192 Verifying\n<\/code><\/pre>\n\n\n\n
ergibt keinen Sinn.<\/p>\n\n\n\n
Diese Regeln m\u00fcssen nicht zwingend in einem gro\u00dfen State-Machine-Framework landen.<\/p>\n\n\n\n
Oft reicht schon eine klare Orchestrierung.<\/p>\n\n\n\n
Aber man sollte sie bewusst besitzen.<\/p>\n\n\n\n
\n\n\n\n
Fehler sind Zust\u00e4nde, nicht nur Exceptions<\/h1>\n\n\n\n
Eine Exception ist ein technisches Ereignis.<\/p>\n\n\n\n
Ein Fehlerzustand ist eine fachliche Situation.<\/p>\n\n\n\n
Beispiel:<\/p>\n\n\n\n
catch {\n    $state.Phase = 'Failed'\n    $state.Error = $_.Exception.Message\n}\n<\/code><\/pre>\n\n\n\n
Der Screen kann dann darstellen:<\/p>\n\n\n\n
PROCESSING FAILED\n\nCompleted\n117 \/ 184\n\nReason\nHTTP 503 Service Unavailable\n\nResume possible\n<\/code><\/pre>\n\n\n\n
Das ist wesentlich besser als:<\/p>\n\n\n\n
Exception calling Invoke-MgGraphRequest...\n<\/code><\/pre>\n\n\n\n
Die Exception bleibt intern wichtig.<\/p>\n\n\n\n
Die TUI zeigt aber den Zustand, den sie verursacht hat.<\/p>\n\n\n\n
\n\n\n\n
Retry ist ein eigener Zustand<\/h1>\n\n\n\n
Retry wird oft nur als Schleife implementiert:<\/p>\n\n\n\n
catch {\n    Start-Sleep -Seconds 5\n    retry\n}\n<\/code><\/pre>\n\n\n\n
F\u00fcr die Anwendung ist aber etwas Relevantes passiert.<\/p>\n\n\n\n
Sie wartet bewusst.<\/p>\n\n\n\n
Also kann das ein Zustand sein:<\/p>\n\n\n\n
RETRYING\n\nServer throttled the request.\n\nRetry 2 \/ 5\nContinuing in 4 seconds\n<\/code><\/pre>\n\n\n\n
Das ist f\u00fcr den Benutzer wesentlich verst\u00e4ndlicher als ein eingefrorener Spinner.<\/p>\n\n\n\n
Auch hier gilt:<\/p>\n\n\n\n
Der Renderer braucht keine Kenntnis \u00fcber HTTP 429.<\/p>\n\n\n\n
Er bekommt:<\/p>\n\n\n\n
$state = [pscustomobject]@{\n    Phase       = 'Retrying'\n    RetryNumber = 2\n    RetryMax    = 5\n    RetryAfter  = 4\n    Reason      = 'Rate limited'\n}\n<\/code><\/pre>\n\n\n\n
\n\n\n\n
Warten ist ebenfalls ein Zustand<\/h1>\n\n\n\n
Ein besonders wichtiger Zustand ist:<\/p>\n\n\n\n
WaitingForConfirmation\n<\/code><\/pre>\n\n\n\n
Denn die Anwendung arbeitet hier nicht.<\/p>\n\n\n\n
Sie wartet auf den Benutzer.<\/p>\n\n\n\n
Das sollte sich visuell unterscheiden von:<\/p>\n\n\n\n
Processing\n<\/code><\/pre>\n\n\n\n
Ein Spinner w\u00e4re hier sogar falsch.<\/p>\n\n\n\n
Denn:<\/p>\n\n\n\n
\u2839 Waiting for confirmation...\n<\/code><\/pre>\n\n\n\n
suggeriert Aktivit\u00e4t.<\/p>\n\n\n\n
Tats\u00e4chlich ist die Anwendung blockiert und braucht eine Entscheidung.<\/p>\n\n\n\n
Besser:<\/p>\n\n\n\n
CONFIRMATION REQUIRED\n\n184 items will be modified.\n\nType FILE to continue.\n<\/code><\/pre>\n\n\n\n
Auch kleine UI-Details werden klarer, sobald der Zustand sauber modelliert ist.<\/p>\n\n\n\n
\n\n\n\n
Ein Spinner geh\u00f6rt nur zu bestimmten Zust\u00e4nden<\/h1>\n\n\n\n
Wenn die Zust\u00e4nde definiert sind, l\u00e4sst sich auch Animation sinnvoll zuordnen.<\/p>\n\n\n\n
Zum Beispiel:<\/p>\n\n\n\n
Zustand<\/th>Sinnvolle Darstellung<\/th><\/tr><\/thead>
Connecting<\/td>Spinner<\/td><\/tr>
Auditing<\/td>Spinner oder Counter<\/td><\/tr>
WaitingForConfirmation<\/td>keine Animation<\/td><\/tr>
Processing<\/td>Progressbar<\/td><\/tr>
Retrying<\/td>Countdown \/ Spinner<\/td><\/tr>
Verifying<\/td>Spinner<\/td><\/tr>
Completed<\/td>statischer Screen<\/td><\/tr>
Failed<\/td>statischer Screen<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Jetzt bekommt Animation eine Semantik.<\/p>\n\n\n\n
Sie ist nicht mehr Dekoration.<\/p>\n\n\n\n
\n\n\n\n
Fortschritt braucht eine Definition<\/h1>\n\n\n\n
Sobald ein State Progress<\/code> enth\u00e4lt, muss klar sein, was er bedeutet.<\/p>\n\n\n\n
Beispiel:<\/p>\n\n\n\n
$state.Processed = 117\n$state.Total = 184\n<\/code><\/pre>\n\n\n\n
Dann:<\/p>\n\n\n\n
117 \/ 184 = 63.6%\n<\/code><\/pre>\n\n\n\n
Aber was bedeutet Processed<\/code>?<\/p>\n\n\n\n
M\u00f6gliche Interpretationen:<\/p>\n\n\n\n
Requests gesendet\nResponses erhalten\nerfolgreiche Operationen\nElemente verifiziert\n<\/code><\/pre>\n\n\n\n
Diese Dinge sind nicht gleich.<\/p>\n\n\n\n
Der Zustand sollte deshalb m\u00f6glichst ehrlich modelliert werden.<\/p>\n\n\n\n
Zum Beispiel:<\/p>\n\n\n\n
$state = [pscustomobject]@{\n    Attempted = 120\n    Succeeded = 117\n    Failed    = 1\n    Retrying  = 2\n    Total     = 184\n}\n<\/code><\/pre>\n\n\n\n
Dann kann die TUI klar sagen:<\/p>\n\n\n\n
117 successful\n1 failed\n2 retrying\n64 remaining\n<\/code><\/pre>\n\n\n\n
Das ist wesentlich informativer als eine vage Zahl.<\/p>\n\n\n\n
\n\n\n\n
Der Zustand sollte die Wahrheit des Systems abbilden<\/h1>\n\n\n\n
Das ist ein wichtiger Grundsatz:<\/p>\n\n\n\n
\n
Die TUI darf nicht mehr wissen als der State.<\/p>\n<\/blockquote>\n\n\n\n
Wenn der State nur sagt:<\/p>\n\n\n\n
184 requests completed\n<\/code><\/pre>\n\n\n\n
darf der Screen nicht behaupten:<\/p>\n\n\n\n
ALL ITEMS VERIFIED\n<\/code><\/pre>\n\n\n\n
Daf\u00fcr braucht es einen separaten Verifikationszustand.<\/p>\n\n\n\n
Zum Beispiel:<\/p>\n\n\n\n
Phase = Verifying\n<\/code><\/pre>\n\n\n\n
und danach:<\/p>\n\n\n\n
Phase = Completed\nRemaining = 0\nVerified = true\n<\/code><\/pre>\n\n\n\n
Dann ist ein gr\u00fcnes:<\/p>\n\n\n\n
VERIFIED\n<\/code><\/pre>\n\n\n\n
auch tats\u00e4chlich gerechtfertigt.<\/p>\n\n\n\n
\n\n\n\n
Zustandsmaschinen reduzieren UI-Bugs<\/h1>\n\n\n\n
Viele klassische TUI-Probleme entstehen dadurch, dass Screens zu viel Eigenlogik besitzen.<\/p>\n\n\n\n
Beispielsweise:<\/p>\n\n\n\n
Wenn $processing und nicht $verifying und $failed -eq 0,\ndann gr\u00fcne Progressbar,\nau\u00dfer $retrying...\n<\/code><\/pre>\n\n\n\n
Mit expliziten Zust\u00e4nden wird daraus:<\/p>\n\n\n\n
Processing\nRetrying\nVerifying\nFailed\n<\/code><\/pre>\n\n\n\n
Das vereinfacht Rendering massiv.<\/p>\n\n\n\n
Statt dutzender Bedingungen:<\/p>\n\n\n\n
if (...) {\n    if (...) {\n        if (...) {\n<\/code><\/pre>\n\n\n\n
gibt es:<\/p>\n\n\n\n
switch ($state.Phase) {\n<\/code><\/pre>\n\n\n\n
Das ist einfacher zu verstehen und zu testen.<\/p>\n\n\n\n
\n\n\n\n
State Explosion vermeiden<\/h1>\n\n\n\n
Nat\u00fcrlich kann man es auch \u00fcbertreiben.<\/p>\n\n\n\n
Man k\u00f6nnte f\u00fcr jedes Detail einen Zustand erfinden:<\/p>\n\n\n\n
ConnectingToApi\nConnectingToMailbox\nLoadingRootFolders\nLoadingHiddenFolders\nLoadingChildFolders\nBuildingQueue\n...\n<\/code><\/pre>\n\n\n\n
Das wird schnell un\u00fcbersichtlich.<\/p>\n\n\n\n
Eine gute Faustregel:<\/p>\n\n\n\n
Ein Zustand sollte relevant sein, wenn er mindestens eine dieser Eigenschaften besitzt:<\/p>\n\n\n\n
    \n
  • andere Benutzerinformation<\/li>\n\n\n\n
  • anderes erlaubtes Verhalten<\/li>\n\n\n\n
  • anderer Fehlerpfad<\/li>\n\n\n\n
  • andere Interaktion<\/li>\n\n\n\n
  • andere Renderinglogik<\/li>\n\n\n\n
  • relevante Wiederaufnahmegrenze<\/li>\n<\/ul>\n\n\n\n
    Nicht jeder interne Funktionsaufruf braucht einen State.<\/p>\n\n\n\n
    \n\n\n\n
    Hauptzustand und Unterzustand<\/h1>\n\n\n\n
    Bei komplexeren Tools kann eine Hierarchie helfen.<\/p>\n\n\n\n
    Zum Beispiel:<\/p>\n\n\n\n
    Processing\n\u251c\u2500\u2500 LoadingBatch\n\u251c\u2500\u2500 SendingBatch\n\u251c\u2500\u2500 WaitingForRetry\n\u2514\u2500\u2500 UpdatingCheckpoint\n<\/code><\/pre>\n\n\n\n
    Die TUI muss vielleicht nur:<\/p>\n\n\n\n
    Processing\n<\/code><\/pre>\n\n\n\n
    darstellen.<\/p>\n\n\n\n
    Intern kann trotzdem ein detaillierterer Substate existieren.<\/p>\n\n\n\n
    Das verhindert, dass das UI-Modell mit Implementierungsdetails \u00fcberladen wird.<\/p>\n\n\n\n
    \n\n\n\n
    State sollte m\u00f6glichst zentral verwaltet werden<\/h1>\n\n\n\n
    Ein h\u00e4ufiger Fehler ist, State \u00fcber das ganze Programm zu verteilen.<\/p>\n\n\n\n
    Zum Beispiel:<\/p>\n\n\n\n
    $Script:Processed\n$Script:Failed\n$Script:CurrentFolder\n$Script:RetryCount\n$Script:IsVerifying\n$Script:StartedAt\n<\/code><\/pre>\n\n\n\n
    Das funktioniert.<\/p>\n\n\n\n
    Aber irgendwann ist schwer nachvollziehbar, welche Funktion welche Variable ver\u00e4ndern darf.<\/p>\n\n\n\n
    Besser ist ein zusammenh\u00e4ngendes Objekt:<\/p>\n\n\n\n
    $state = [pscustomobject]@{\n    Phase         = 'Processing'\n    CurrentFolder = $null\n    Processed     = 0\n    Failed        = 0\n    Retried       = 0\n    Total         = 0\n    StartedAt     = Get-Date\n}\n<\/code><\/pre>\n\n\n\n
    Dann wird klar:<\/p>\n\n\n\n
    Application State\n<\/code><\/pre>\n\n\n\n
    ist eine eigene Einheit.<\/p>\n\n\n\n
    \n\n\n\n
    Noch besser: kontrollierte Zustands\u00e4nderungen<\/h1>\n\n\n\n
    Bei gr\u00f6\u00dferen Tools kann man \u00c4nderungen \u00fcber Funktionen laufen lassen:<\/p>\n\n\n\n
    Set-FBState -Phase Processing\nUpdate-FBProgress -Processed 117 -Failed 0\n<\/code><\/pre>\n\n\n\n
    oder \u00fcber Events:<\/p>\n\n\n\n
    Publish-FBEvent -Type ItemProcessed -Data $item\n<\/code><\/pre>\n\n\n\n
    Der Vorteil:<\/p>\n\n\n\n
    Zustands\u00e4nderungen sind zentral kontrollierbar.<\/p>\n\n\n\n
    Man kann dabei:<\/p>\n\n\n\n
      \n
    • validieren<\/li>\n\n\n\n
    • loggen<\/li>\n\n\n\n
    • rendern<\/li>\n\n\n\n
    • testen<\/li>\n<\/ul>\n\n\n\n
      Das ist besonders wertvoll, wenn mehrere UI-Modi existieren.<\/p>\n\n\n\n
      \n\n\n\n
      TUI und Orchestrator sind unterschiedliche Dinge<\/h1>\n\n\n\n
      Die Zustandsmaschine geh\u00f6rt konzeptionell eher zum Orchestrator als zum Renderer.<\/p>\n\n\n\n
      Der Orchestrator entscheidet:<\/p>\n\n\n\n
      Connecting\n\u2193\nAuditing\n\u2193\nConfirmation\n\u2193\nProcessing\n<\/code><\/pre>\n\n\n\n
      Der Renderer sagt nur:<\/p>\n\n\n\n
      Wenn Connecting:\nzeige Connecting Screen\n<\/code><\/pre>\n\n\n\n
      Also:<\/p>\n\n\n\n
      Orchestrator\n    \u2502\n    \u2502 changes State\n    \u25bc\nState\n    \u2502\n    \u25bc\nRenderer\n<\/code><\/pre>\n\n\n\n
      Nicht:<\/p>\n\n\n\n
      Renderer\n    \u2193\nentscheidet, was als N\u00e4chstes passiert\n<\/code><\/pre>\n\n\n\n
      Das ist eine wichtige Grenze.<\/p>\n\n\n\n
      \n\n\n\n
      Der Renderer sollte m\u00f6glichst deterministisch sein<\/h1>\n\n\n\n
      Idealerweise gilt:<\/p>\n\n\n\n
      gleicher State\n=\ngleicher Screen\n<\/code><\/pre>\n\n\n\n
      Das macht Rendering testbar.<\/p>\n\n\n\n
      Wenn:<\/p>\n\n\n\n
      $state = @{\n    Phase = 'Completed'\n    Processed = 184\n    Failed = 0\n    Remaining = 0\n}\n<\/code><\/pre>\n\n\n\n
      dann sollte immer derselbe Completion Screen entstehen.<\/p>\n\n\n\n
      Der Renderer braucht daf\u00fcr keine API.<\/p>\n\n\n\n
      Keine Dateien.<\/p>\n\n\n\n
      Keine Business Rules.<\/p>\n\n\n\n
      Nur State.<\/p>\n\n\n\n
      \n\n\n\n
      Screenshots werden dadurch reproduzierbar<\/h1>\n\n\n\n
      Das hat einen angenehmen Nebeneffekt.<\/p>\n\n\n\n
      Man kann UI-Zust\u00e4nde isoliert entwickeln.<\/p>\n\n\n\n
      Zum Beispiel:<\/p>\n\n\n\n
      $testState = [pscustomobject]@{\n    Phase         = 'Processing'\n    CurrentFolder = 'Inbox \/ Archive \/ 2026'\n    Processed     = 125\n    Total         = 184\n    Failed        = 2\n}\n<\/code><\/pre>\n\n\n\n
      Dann:<\/p>\n\n\n\n
      Show-ProcessingScreen -State $testState\n<\/code><\/pre>\n\n\n\n
      Keine echte API-Verbindung n\u00f6tig.<\/p>\n\n\n\n
      Keine 184 echten Nachrichten.<\/p>\n\n\n\n
      Keine Wartezeit.<\/p>\n\n\n\n
      Damit wird TUI-Design pl\u00f6tzlich viel angenehmer.<\/p>\n\n\n\n
      \n\n\n\n
      Fehlerzust\u00e4nde lassen sich ebenfalls simulieren<\/h1>\n\n\n\n
      Zum Beispiel:<\/p>\n\n\n\n
      $testState = [pscustomobject]@{\n    Phase     = 'Failed'\n    Processed = 125\n    Total     = 184\n    Error     = 'HTTP 503 Service Unavailable'\n    CanResume = $true\n}\n<\/code><\/pre>\n\n\n\n
      Damit l\u00e4sst sich der Fehler-Screen jederzeit pr\u00fcfen.<\/p>\n\n\n\n
      Das ist ein gro\u00dfer Unterschied zu einer UI, die nur sichtbar wird, wenn zuf\u00e4llig ein echter Fehler auftritt.<\/p>\n\n\n\n
      \n\n\n\n
      Zustandsmaschinen verbessern Tests<\/h1>\n\n\n\n
      Auch funktionale Tests werden einfacher.<\/p>\n\n\n\n
      Man kann beispielsweise pr\u00fcfen:<\/p>\n\n\n\n
      Initial State\n= Initializing\n<\/code><\/pre>\n\n\n\n
      Nach erfolgreicher Authentifizierung:<\/p>\n\n\n\n
      Connecting\n\u2192 Auditing\n<\/code><\/pre>\n\n\n\n
      Nach Best\u00e4tigung:<\/p>\n\n\n\n
      WaitingForConfirmation\n\u2192 Processing\n<\/code><\/pre>\n\n\n\n
      Nach erfolgreicher Verarbeitung:<\/p>\n\n\n\n
      Processing\n\u2192 Verifying\n<\/code><\/pre>\n\n\n\n
      Nach Verifikation:<\/p>\n\n\n\n
      Verifying\n\u2192 Completed\n<\/code><\/pre>\n\n\n\n
      Bei Fehler:<\/p>\n\n\n\n
      Processing\n\u2192 Failed\n<\/code><\/pre>\n\n\n\n
      Das ist wesentlich pr\u00e4ziser als zu testen, ob irgendwo:<\/p>\n\n\n\n
      \"Success\"\n<\/code><\/pre>\n\n\n\n
      ausgegeben wurde.<\/p>\n\n\n\n
      \n\n\n\n
      Resume braucht Zustand<\/h1>\n\n\n\n
      Sp\u00e4testens bei Wiederaufnahme wird State unvermeidlich.<\/p>\n\n\n\n
      Angenommen, eine Operation verarbeitet:<\/p>\n\n\n\n
      184 Elemente\n<\/code><\/pre>\n\n\n\n
      Nach 120 Elementen bricht das Programm ab.<\/p>\n\n\n\n
      Ein Checkpoint k\u00f6nnte enthalten:<\/p>\n\n\n\n
      {\n  \"phase\": \"processing\",\n  \"processed\": 120,\n  \"succeededIds\": [\n    \"...\"\n  ],\n  \"startedAt\": \"2026-09-05T14:00:00Z\"\n}\n<\/code><\/pre>\n\n\n\n
      Beim n\u00e4chsten Start entsteht:<\/p>\n\n\n\n
      RESUMING\n<\/code><\/pre>\n\n\n\n
      als eigener sinnvoller Zustand.<\/p>\n\n\n\n
      Die TUI k\u00f6nnte anzeigen:<\/p>\n\n\n\n
      RESUMING PREVIOUS RUN\n\n120 items already completed\n64 items remaining\n<\/code><\/pre>\n\n\n\n
      Ohne explizites Zustandsmodell wirkt Resume schnell wie ein angeklebtes Sonderfeature.<\/p>\n\n\n\n
      \n\n\n\n
      Persistierter Zustand ist nicht automatisch UI-State<\/h1>\n\n\n\n
      Dabei sollte man zwei Dinge unterscheiden.<\/p>\n\n\n\n
      Persistenter Arbeitszustand:<\/p>\n\n\n\n
      welche IDs sind bereits erfolgreich?\nwelcher Run war aktiv?\n<\/code><\/pre>\n\n\n\n
      UI-State:<\/p>\n\n\n\n
      welcher Screen wird angezeigt?\nwelcher Ordner ist aktuell?\nwelche Animation l\u00e4uft?\n<\/code><\/pre>\n\n\n\n
      Nicht alles muss gespeichert werden.<\/p>\n\n\n\n
      Nach einem Neustart ist beispielsweise egal, welches Spinner-Frame zuletzt sichtbar war.<\/p>\n\n\n\n
      Relevant ist nur der fachliche Zustand.<\/p>\n\n\n\n
      Das ist ein gutes Beispiel f\u00fcr die Trennung von:<\/p>\n\n\n\n
      Domain State\nUI State\n<\/code><\/pre>\n\n\n\n
      \n\n\n\n
      Domain State und UI State<\/h1>\n\n\n\n
      Ein sauberes Modell k\u00f6nnte so aussehen:<\/p>\n\n\n\n
      Domain State\n\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\nProcessed\nFailed\nRemaining\nCurrentItem\nVerificationResult\n\nUI State\n\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\nCurrentScreen\nLastRenderTime\nSpinnerFrame\nTerminalWidth\nAnimationEnabled\n<\/code><\/pre>\n\n\n\n
      Der Renderer verwendet beide.<\/p>\n\n\n\n
      Die Gesch\u00e4ftslogik sollte aber nur Domain State kennen.<\/p>\n\n\n\n
      \n\n\n\n
      Warum das gegen Flackern hilft<\/h1>\n\n\n\n
      Interessanterweise verbessert ein sauberes State-Modell auch das Rendering.<\/p>\n\n\n\n
      Wenn die UI wei\u00df:<\/p>\n\n\n\n
      State vorher = Processing\nState jetzt   = Processing\n<\/code><\/pre>\n\n\n\n
      dann braucht sie keinen Full Clear.<\/p>\n\n\n\n
      Nur ein Live Update.<\/p>\n\n\n\n
      Wenn dagegen:<\/p>\n\n\n\n
      State vorher = Processing\nState jetzt   = Verifying\n<\/code><\/pre>\n\n\n\n
      kann sie bewusst einen Screen Transition durchf\u00fchren.<\/p>\n\n\n\n
      Damit ergibt sich automatisch:<\/p>\n\n\n\n
      same state\n\u2192 in-place redraw\n\nstate transition\n\u2192 full redraw\n<\/code><\/pre>\n\n\n\n
      Das ist wesentlich sauberer als \u00fcberall manuell zu entscheiden, wann Clear-Host<\/code> ausgef\u00fchrt wird.<\/p>\n\n\n\n
      \n\n\n\n
      Rendering wird vom State Change getrieben<\/h1>\n\n\n\n
      Damit kann man ein sehr einfaches Modell bauen:<\/p>\n\n\n\n
      if ($PreviousState.Phase -ne $CurrentState.Phase) {\n    Invoke-ScreenTransition\n}\n\nRender-State $CurrentState\n<\/code><\/pre>\n\n\n\n
      Zus\u00e4tzlich k\u00f6nnen Live-Updates gedrosselt werden:<\/p>\n\n\n\n
      if ((Get-Date) - $LastRender -gt 150ms) {\n    Render-State $CurrentState\n}\n<\/code><\/pre>\n\n\n\n
      Die Zustandsmaschine liefert also nicht nur semantische Klarheit.<\/p>\n\n\n\n
      Sie liefert auch eine Grundlage f\u00fcr effizientes Rendering.<\/p>\n\n\n\n
      \n\n\n\n
      Animation ist ein Detail des Renderers<\/h1>\n\n\n\n
      Jetzt kann der Spinner endlich an die richtige Stelle.<\/p>\n\n\n\n
      Zum Beispiel:<\/p>\n\n\n\n
      if ($State.Phase -eq 'Connecting') {\n    $frame = Get-SpinnerFrame\n}\n<\/code><\/pre>\n\n\n\n
      Die Engine wei\u00df nicht, dass ein Spinner existiert.<\/p>\n\n\n\n
      Das ist genau richtig.<\/p>\n\n\n\n
      Wenn Animation deaktiviert wird:<\/p>\n\n\n\n
      -NoAnimation\n<\/code><\/pre>\n\n\n\n
      \u00e4ndert sich:<\/p>\n\n\n\n
      Connecting\n<\/code><\/pre>\n\n\n\n
      nicht.<\/p>\n\n\n\n
      Nur seine Darstellung.<\/p>\n\n\n\n
      Vielleicht:<\/p>\n\n\n\n
      \u2839 Connecting...\n<\/code><\/pre>\n\n\n\n
      wird zu:<\/p>\n\n\n\n
      Connecting...\n<\/code><\/pre>\n\n\n\n
      Der Anwendungszustand bleibt identisch.<\/p>\n\n\n\n
      \n\n\n\n
      Dasselbe gilt f\u00fcr Farben<\/h1>\n\n\n\n
      Wenn:<\/p>\n\n\n\n
      Phase = Failed\n<\/code><\/pre>\n\n\n\n
      dann kann der Renderer entscheiden:<\/p>\n\n\n\n
      Rot\n[ERROR]\n<\/code><\/pre>\n\n\n\n
      Ein Plain Renderer k\u00f6nnte dagegen nur schreiben:<\/p>\n\n\n\n
      ERROR: Processing failed\n<\/code><\/pre>\n\n\n\n
      Und JSON:<\/p>\n\n\n\n
      {\n  \"phase\": \"failed\"\n}\n<\/code><\/pre>\n\n\n\n
      Wieder:<\/p>\n\n\n\n
      State bleibt gleich\nDarstellung \u00e4ndert sich\n<\/code><\/pre>\n\n\n\n
      Genau so sollte es sein.<\/p>\n\n\n\n
      \n\n\n\n
      Machine Output profitiert davon besonders<\/h1>\n\n\n\n
      Ein guter State l\u00e4sst sich fast direkt serialisieren.<\/p>\n\n\n\n
      Zum Beispiel:<\/p>\n\n\n\n
      $state | ConvertTo-Json\n<\/code><\/pre>\n\n\n\n
      Nat\u00fcrlich sollte ein \u00f6ffentliches JSON-Schema bewusst definiert werden.<\/p>\n\n\n\n
      Aber konzeptionell ist die N\u00e4he hilfreich.<\/p>\n\n\n\n
      Das verhindert, dass TUI und -Quiet<\/code> unterschiedliche Vorstellungen vom Ergebnis entwickeln.<\/p>\n\n\n\n
      Beide basieren auf derselben Wahrheit.<\/p>\n\n\n\n
      \n\n\n\n
      Die Zustandsmaschine sollte nicht zum Selbstzweck werden<\/h1>\n\n\n\n
      Nat\u00fcrlich braucht ein kleines Skript kein Framework mit:<\/p>\n\n\n\n
      StateFactory\nStateTransitionManager\nStateRepository\nStateObserverProvider\n<\/code><\/pre>\n\n\n\n
      Ein einfacher switch<\/code> und ein State-Objekt k\u00f6nnen v\u00f6llig ausreichen.<\/p>\n\n\n\n
      Zum Beispiel:<\/p>\n\n\n\n
      $state.Phase = 'Connecting'\n\nConnect-Service\n\n$state.Phase = 'Processing'\n\nInvoke-Processing\n\n$state.Phase = 'Verifying'\n\nInvoke-Verification\n\n$state.Phase = 'Completed'\n<\/code><\/pre>\n\n\n\n
      Das ist bereits viel besser, als State nur implizit \u00fcber Ausgaben zu definieren.<\/p>\n\n\n\n
      Architektur ist nicht die Zahl der Abstraktionen.<\/p>\n\n\n\n
      Architektur ist Klarheit \u00fcber Verantwortlichkeiten.<\/p>\n\n\n\n
      \n\n\n\n
      Eine praktische Reihenfolge<\/h1>\n\n\n\n
      Wenn ich heute eine neue TUI-Anwendung bauen w\u00fcrde, w\u00e4re die Reihenfolge:<\/p>\n\n\n\n
      1. Fachlichen Ablauf definieren<\/h2>\n\n\n\n
      Connect\nDiscover\nConfirm\nProcess\nVerify\n<\/code><\/pre>\n\n\n\n
      2. Zust\u00e4nde daraus ableiten<\/h2>\n\n\n\n
      Connecting\nAuditing\nWaitingForConfirmation\nProcessing\nVerifying\nCompleted\n<\/code><\/pre>\n\n\n\n
      3. Fehler- und Sonderzust\u00e4nde erg\u00e4nzen<\/h2>\n\n\n\n
      Retrying\nFailed\nCancelled\nResuming\n<\/code><\/pre>\n\n\n\n
      4. Daten pro Zustand definieren<\/h2>\n\n\n\n
      Beispiel:<\/p>\n\n\n\n
      Processing:\nCurrentItem\nProcessed\nTotal\nFailed\n\nRetrying:\nRetryNumber\nRetryAfter\nReason\n\nCompleted:\nProcessed\nFailed\nRemaining\nVerified\n<\/code><\/pre>\n\n\n\n
      5. Erst danach Screens bauen<\/h2>\n\n\n\n
      Show-ProcessingScreen\nShow-RetryScreen\nShow-CompletedScreen\n<\/code><\/pre>\n\n\n\n
      6. Danach Rendering optimieren<\/h2>\n\n\n\n
      Cursor Home\nClear Below\nThrottle\nResponsive Width\n<\/code><\/pre>\n\n\n\n
      7. Ganz am Ende Animation<\/h2>\n\n\n\n
      Spinner\nPulse\nTransitions\nCompletion Effect\n<\/code><\/pre>\n\n\n\n
      Das ist fast die umgekehrte Reihenfolge, in der solche Tools oft spontan entstehen.<\/p>\n\n\n\n
      \n\n\n\n
      Warum der Spinner zuletzt kommt<\/h1>\n\n\n\n
      Der Spinner ist visuell auff\u00e4llig.<\/p>\n\n\n\n
      Architektonisch ist er aber trivial.<\/p>\n\n\n\n
      Er beantwortet nur:<\/p>\n\n\n\n
      \n
      Wie visualisiere ich einen laufenden, nicht exakt messbaren Zustand?<\/p>\n<\/blockquote>\n\n\n\n
      Wenn nicht einmal klar ist, was:<\/p>\n\n\n\n
      laufend\n<\/code><\/pre>\n\n\n\n
      bedeutet, ist der Spinner zu fr\u00fch.<\/p>\n\n\n\n
      Wenn State und Renderer dagegen sauber getrennt sind, ist seine Implementierung fast nebens\u00e4chlich.<\/p>\n\n\n\n
      Das ist die eigentliche Pointe.<\/p>\n\n\n\n
      \n\n\n\n
      Ein schlechtes Beispiel<\/h1>\n\n\n\n
      Angenommen:<\/p>\n\n\n\n
      Write-Host \"Connecting\"\n\nConnect-Service\n\nClear-Host\nWrite-Host \"Processing\"\n\nforeach ($item in $items) {\n    Write-Host \"Processing $item\"\n}\n\nClear-Host\nWrite-Host \"Done\"\n<\/code><\/pre>\n\n\n\n
      Die Zust\u00e4nde existieren zwar.<\/p>\n\n\n\n
      Aber nur implizit in der Reihenfolge der Ausgabe.<\/p>\n\n\n\n
      Wenn jetzt Retry hinzukommt:<\/p>\n\n\n\n
      catch {\n    Write-Host \"Retrying\"\n}\n<\/code><\/pre>\n\n\n\n
      und sp\u00e4ter Verification:<\/p>\n\n\n\n
      Write-Host \"Verifying\"\n<\/code><\/pre>\n\n\n\n
      beginnt die UI den Ablauf zu definieren.<\/p>\n\n\n\n
      Das wird zunehmend schwer zu kontrollieren.<\/p>\n\n\n\n
      \n\n\n\n
      Dasselbe mit explizitem State<\/h1>\n\n\n\n
      Stattdessen:<\/p>\n\n\n\n
      $state.Phase = 'Connecting'\nRender-State $state\n\nConnect-Service\n\n$state.Phase = 'Processing'\nRender-State $state\n\nforeach ($item in $items) {\n    $state.CurrentItem = $item\n    $state.Processed++\n    Render-State $state\n}\n\n$state.Phase = 'Verifying'\nRender-State $state\n\n$verification = Invoke-Verification\n\n$state.Phase = 'Completed'\n$state.Verified = $verification.Success\nRender-State $state\n<\/code><\/pre>\n\n\n\n
      Jetzt ist die Darstellung austauschbar.<\/p>\n\n\n\n
      Und der Ablauf bleibt verst\u00e4ndlich.<\/p>\n\n\n\n
      \n\n\n\n
      Der entscheidende Test<\/h1>\n\n\n\n
      Eine einfache Frage zeigt schnell, ob die Architektur stimmt:<\/p>\n\n\n\n
      \n
      Kann ich die Anwendung komplett ohne Terminaloberfl\u00e4che ausf\u00fchren?<\/p>\n<\/blockquote>\n\n\n\n
      Wenn ja, ist die Zustandsmaschine wahrscheinlich von der TUI getrennt.<\/p>\n\n\n\n
      Zum Beispiel:<\/p>\n\n\n\n
      Engine\n\u2192 State\n\u2192 JSON\n<\/code><\/pre>\n\n\n\n
      statt:<\/p>\n\n\n\n
      Engine\n\u2192 TUI\n\u2192 irgendwie Ergebnis\n<\/code><\/pre>\n\n\n\n
      Ein zweiter Test:<\/p>\n\n\n\n
      \n
      Kann ich jeden Screen mit k\u00fcnstlichem State anzeigen?<\/p>\n<\/blockquote>\n\n\n\n
      Wenn ja, ist der Renderer wahrscheinlich sauber getrennt.<\/p>\n\n\n\n
      Beide Tests zusammen sind sehr stark.<\/p>\n\n\n\n
      \n\n\n\n
      Die TUI ist nicht das Programm<\/h1>\n\n\n\n
      Das ist vielleicht die wichtigste Erkenntnis.<\/p>\n\n\n\n
      Eine gute TUI kann sich wie das Programm anf\u00fchlen.<\/p>\n\n\n\n
      Sie ist es aber nicht.<\/p>\n\n\n\n
      Das Programm besteht aus:<\/p>\n\n\n\n
      Business Logic\nState\nLifecycle\nError Handling\n<\/code><\/pre>\n\n\n\n
      Die TUI ist nur eine m\u00f6gliche Oberfl\u00e4che darauf.<\/p>\n\n\n\n
                       Application\n                      \u2502\n                    State\n                      \u2502\n          \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n          \u2502           \u2502           \u2502\n         TUI         JSON        Log\n<\/code><\/pre>\n\n\n\n
      Wenn diese Trennung gelingt, wird fast alles einfacher:<\/p>\n\n\n\n
        \n
      • Tests<\/li>\n\n\n\n
      • Quiet Mode<\/li>\n\n\n\n
      • Automation<\/li>\n\n\n\n
      • Fehlerbehandlung<\/li>\n\n\n\n
      • Resume<\/li>\n\n\n\n
      • Rendering<\/li>\n\n\n\n
      • Animation<\/li>\n<\/ul>\n\n\n\n
        \n\n\n\n
        Fazit<\/h1>\n\n\n\n
        Bei einer Terminalanwendung ist die Versuchung gro\u00df, mit dem sichtbaren Teil zu beginnen.<\/p>\n\n\n\n
        Banner.<\/p>\n\n\n\n
        Farben.<\/p>\n\n\n\n
        Spinner.<\/p>\n\n\n\n
        Progressbar.<\/p>\n\n\n\n
        Transitions.<\/p>\n\n\n\n
        Aber diese Dinge sind nur Darstellungen.<\/p>\n\n\n\n
        Unter ihnen liegt etwas Wichtigeres:<\/p>\n\n\n\n
        Was macht die Anwendung gerade?\n<\/code><\/pre>\n\n\n\n
        Diese Frage sollte jederzeit eindeutig beantwortbar sein.<\/p>\n\n\n\n
        Deshalb ist die richtige Reihenfolge:<\/p>\n\n\n\n
        Operation\n   \u2193\nState\n   \u2193\nState Transition\n   \u2193\nRenderer\n   \u2193\nScreen\n   \u2193\nAnimation\n<\/code><\/pre>\n\n\n\n
        Nicht:<\/p>\n\n\n\n
        Spinner\n   \u2193\nnoch ein Spinner\n   \u2193\nif\n   \u2193\nClear-Host\n   \u2193\nmehr State irgendwie nachbauen\n<\/code><\/pre>\n\n\n\n
        Die wichtigste Regel lautet daher:<\/p>\n\n\n\n
        \n
        Erst die Zustandsmaschine, dann der Spinner.<\/strong><\/p>\n<\/blockquote>\n\n\n\n
        Wenn der Zustand sauber modelliert ist, wird die TUI fast automatisch einfacher.<\/p>\n\n\n\n
        Wenn der Zustand nicht sauber modelliert ist, kann selbst ein Spinner zum Architekturproblem werden.<\/p>\n","protected":false},"excerpt":{"rendered":"
        Bei Terminalanwendungen beginnt die Arbeit oft an der falschen Stelle. Man hat eine Idee f\u00fcr ein Tool, baut die eigentliche Funktion und m\u00f6chte dann schnell etwas Feedback im Terminal anzeigen. Also kommt zuerst: Dann: Dann ein Spinner. Dann Farben. Dann eine Progressbar. Dann ein Banner. Dann \u00dcberg\u00e4nge. Dann ein finaler Erfolgs-Screen. Das Ergebnis sieht irgendwann […]<\/p>\n","protected":false},"author":1,"featured_media":336,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[60,27,8,25,59],"tags":[],"class_list":["post-326","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-automation","category-programming-principles","category-software-architecture","category-software-engineering","category-system-engineering"],"_links":{"self":[{"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=\/wp\/v2\/posts\/326","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=326"}],"version-history":[{"count":1,"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=\/wp\/v2\/posts\/326\/revisions"}],"predecessor-version":[{"id":327,"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=\/wp\/v2\/posts\/326\/revisions\/327"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=\/wp\/v2\/media\/336"}],"wp:attachment":[{"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=326"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=326"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=326"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}