Formtest Entwicklerdoku

Appearance

Server-Sync ​

Entity-Stores werden über das Dexie-Sync-Plugin synchronisiert, das in app/plugins/03.dexieSync.client.ts registriert ist.

Plugin-Einstieg ​

Das Plugin läuft für Pinia-Stores, die auf einen Entity-Helper aufgelöst werden können.

  • die Helper-Auflösung verwendet zuerst options.dexie?.helper
  • andernfalls wird allHelpers[store.$id] verwendet, wenn die Store-ID einem Entity-Namen entspricht
  • Stores können das Plugin mit options.dexie?.enabled === false deaktivieren

Architekturdiagramm ​

Runtime-Bausteine ​

Das Plugin baut ein Runtime-Objekt auf und verdrahtet anschließend drei interne Ebenen:

  • createDexieDirtyState(...)
  • createDexiePersistence(...)
  • createDexieServerSync(...)

Diese Ebenen werden über createDexieStoreExtension(...) und installDexieStoreProperties(...) koordiniert.

Vom Plugin ergänzte Store-Fähigkeiten ​

Erweiterte Stores erhalten zusätzliche Runtime-Felder und Methoden wie:

  • $isDirty
  • $clientUpdatedAt
  • $reloadFromDB
  • $saveToDB
  • $markClean
  • $clearCurrentAcceptance
  • $getStats
  • $saveToServer
  • $loadFromServer

Dirty-Tracking ​

Das Dirty-Tracking ist in app/utils/dexie-sync/dirty-state.ts implementiert.

Wesentliches Verhalten:

  • hasht Store-Einträge nach dem Entfernen serververwalteter Timestamps
  • persistiert saubere Baselines in der Tabelle dirtyFlags
  • ignoriert generierte leere Zeilen
  • beobachtet Acceptance-Wechsel und Entry-Mutationen
  • nutzt für Entry-Mutationen eine interne Revisionsnummer statt JSON.stringify(runtime.getEntries()) als Watch-Quelle, damit große Tabellen nicht bei jeder Änderung komplett serialisiert werden

Lokale Persistenz ​

Die Persistenz ist in app/utils/dexie-sync/persistence.ts implementiert.

Wesentliches Verhalten:

  • lädt alle Zeilen der aktiven Acceptance in den Store
  • speichert diff-basiert: gelöschte Zeilen werden per ID entfernt, neue oder geänderte Zeilen werden gespeichert, unveränderte Zeilen bleiben in IndexedDB unangetastet
  • fällt auf das alte vollständige Ersetzen zurück, wenn ein Entity-Helper keine Löschmethode bereitstellt
  • erstellt automatisch einen minimalen Acceptance-Header, wenn lokale Entity-Daten gespeichert werden, bevor die Acceptance lokal existiert
  • prüft den Acceptance-Header über eine günstige Existenzabfrage, statt den vollständigen Datensatz zu laden

Server-Synchronisation ​

Die Server-Kommunikation ist in app/utils/dexie-sync/server-sync.ts implementiert.

Wesentliches Verhalten:

  • verwendet den pro Store konfigurierten Endpoint oder standardmäßig /${storeId}
  • ergänzt immer acceptanceId
  • setzt nach erfolgreichem Laden oder Speichern die Dirty-Baseline zurück
  • kann servergelöschte Zeilen bei Bedarf hart aus dem Store-Speicher entfernen

Speichern bis zum Endpoint ​

Sync-Strategie auf Acceptance-Ebene ​

Der Editor verwendet app/composables/app/useEntitySync.ts für Entscheidungen auf Acceptance-Ebene.

Im Code verifiziertes Verhalten:

  • im Offline-Modus werden lokale Daten geladen, wenn vorhanden
  • wenn lokale Child-Stores dirty sind, hat der lokale Zustand Vorrang vor eingehenden Server-Daten
  • Feldvergleiche können serverseitige Änderungen markieren
  • Acceptances mit bewusst behaltenen lokalen Änderungen werden zusätzlich im Local Storage nachgehalten