Frontend-Zustandsmodell nach dem WebSocket-Umbau

Wegwerf-Prototyp zu Ticket 10 der Map websocket-realtime. Nur zum Durchklicken — kein Produktionscode.

Die Frage, die dieser Prototyp beantwortet

Der Client hält Verbindungen zu mehreren unabhängigen Servern. Der Rust-Layer besitzt die Verbindungen, führt die Cursor und lädt selbst nach; das Frontend bekommt fertige Entitäten geliefert und hat keine Cursor-Logik. Trägt dieses Zustandsmodell die unangenehmen Fälle — Nachricht in einer nicht geöffneten Conversation, optimistisch gesendete Nachricht, die gleich nochmal vom Server kommt, Bearbeitung, Löschung, erzwungener Neuabgleich, und ein einzelner ausgefallener Server neben funktionierenden?

Die beiden Schalter unten sind die eigentlich offenen Entscheidungen. Stell sie um und fahr dieselben Durchläufe nochmal — der Unterschied ist der Punkt.

Rust lädt auch für nicht geöffnete Conversations nach. Aus: es kommt nur ein Signal, der Inhalt wird erst beim Öffnen geholt. Der Client vergibt die Nachrichten-ID. Aus: der Server vergibt sie, der Client muss die eigene Nachricht am Echo wiedererkennen.

Aktueller Zustand

Was gerade passiert ist

Freies Ausprobieren

Geführte Durchläufe

Prototyp — wird nicht ausgeliefert. Der Reducer im ersten <script>-Block ist der Teil, der in echten Code übernommen werden kann; die Seite drumherum nicht.