Der bekannteste Rat zum Thema App State Management ist auch der am wenigsten hilfreiche: Nutze einen globalen Store für alles. Dieser Ansatz behandelt API Responses, die Sichtbarkeit von Modals, ungespeicherte Formular-Inputs, Authentifizierung und Navigationsfilter so, als hätten sie denselben Lifecycle. Das haben sie nicht. Eine Capacitor oder Electron-App läuft über einen Web-Layer und eine native oder Desktop-Runtime, daher muss der State getrennt werden nach woher es kommt, wie lange es bestehen bleibt, wer dafür verantwortlich ist und was passiert, wenn das Netzwerk oder der Prozess abbricht.
State Management ist essenziell, weil mobile Runtimes volatil sind. Apps können nach Orientierungswechseln oder bei Speichermangel zerstört und neu erstellt werden. Android bietet dafür Instance-State-Restoration und Lifecycle-Callbacks wie onSaveInstanceState() aus diesem Grund, wie in einem UC-Riverside-Studie zu zuverlässigem State-Management für mobile Apps. Dieselbe Studie untersuchte 966 Apps und 4.808 Aktivitäten, wobei sie feststellte, dass 452 Apps (46,8 %) mindestens eine Aktivität mit nicht leerem State hatten, während 1.896 Aktivitäten insgesamt einen nicht leeren State aufwiesen. State ist keine optionale Abstraktion, die man erst hinzufügt, wenn die UI funktioniert. Er ist Teil des Runtime-Contracts.
Inhaltsverzeichnis
- Das Global-Store-Modell neu denken
- Architektur-Patterns für Cross-Platform-Apps
- Persistenz und Offline-First-Synchronisation
- Performance-Tuning und Teststrategien
- Plattform-Guide für Capacitor und Electron
- Migration zu einer modernen Hybrid-Architektur
- Best Practices und häufige Fehler
Das Global-Store-Modell neu denken
Redux vs. Context vs. MobX ist der falsche Ansatz. Ein Store kann Updates koordinieren, aber er kann nicht entscheiden, ob ein Wert zum Server, zum aktuellen Screen, zu einem Formular-Workflow oder zur Adressleiste gehört. Alles in einen globalen Container zu packen, führt zu redundanten API Caches, veralteten URL-Parametern und Subscriptions, die unnötige Rerenders auf anderen Screens auslösen.
Ein robustes Design weist jedem Wert einen Owner und eine Recovery-Policy zu:
- Server State gehört zur Data-Fetching- und Caching-Layer. API Responses, Loading-Status, Errors, Freshness, Invalidation und Retries beschreiben alle eine Remote-Resource. Der Server bleibt die Authority, daher sollte der Client keine zweite permanente Source of Truth vorhalten.
- Client- oder UI State bleibt nah an der Komponente oder dem Feature, das ihn besitzt. Modal-Visibility, ausgewählte Tabs, expandierte Zeilen, Theme-Präferenzen und temporäre Interaktions-Flags benötigen meist keine app-weite Persistenz.
- Form State folgt einem eigenen Workflow. Entwurfseingaben, Validierungsmeldungen, Dirty-Status und Submission-Fortschritt müssen die Navigation innerhalb eines Formulars eventuell überleben, sollten aber nicht automatisch zu geteiltem Business-State werden.
- URL-State gehört zum Router. Suchbegriffe, Filter, Sortierauswahl und Pagination in der Adressleiste können als Lesezeichen gespeichert, geteilt, wiederhergestellt und inspiziert werden, ohne sie in einen anderen Store zu kopieren.
Warum ein einziger Store die Architektur ausbremst
Die 2024er detaillierte Review zum Application State Management untersucht das State Management in Web- und Mobile-Apps. Die Betrachtung spiegelt den praktischen Wandel von verstreuten UI-Variablen hin zu einer expliziten, Lifecycle-bewussten Architektur wider. Androids Weg von Instance-State-Bundles zu ViewModel und SavedStateHandle geht in dieselbe Richtung, bedeutet aber nicht, dass jeder Wert in einen gemeinsamen Container gehört.
Ein globaler Store hat weiterhin eine klar definierte Rolle. Session-Identität, Berechtigungen, App-Einstellungen, Connectivity-Policies und gezielt abgegrenzte Cross-Feature-Workflows können eine gemeinsame Ownership erfordern. Probleme entstehen, wenn der Store zum Sammelbecken für Werte wird, die eigentlich einen passenderen Owner hätten.
Praktische Regel: Wenn ein Wert aus dem Server, der URL oder der aktuellen Komponente rekonstruiert werden kann, sollte er nicht im globalen State liegen, es sei denn, ein spezifischer Workflow erfordert dies.
Diese Abgrenzung unterstützt auch unabhängig verantwortete Module. Teams, die ein Produkt in deploybare Bereiche aufteilen, können die Ownership-Prinzipien anwenden, die in Micro-Frontend-Architektur, anstatt einen einzigen Abhängigkeitsgraphen über die gesamte Anwendung aufzubauen. In einer Capacitor- oder Electron-Codebase funktioniert ein hybrides Modell besser: Remote-Daten nutzen Cache- und Synchronisationsregeln, UI-Werte bleiben lokal, und dauerhafter Workflow-State wird explizit persistiert. Diese Trennung begrenzt konkurrierende Writer und macht die Wiederherstellung nach Reloads, suspendierten Prozessen oder Offline-Phasen besser nachvollziehbar.
Architektur-Patterns für Cross-Platform-Apps
Sobald ein State einen Besitzer hat, wird die Auswahl der Implementierung deutlich eingeschränkter. Die meisten clientseitigen States folgen einem von drei Mustern: lokaler Component-State, ein kleiner Shared Store, oder eventgesteuerte Kommunikation zwischen isolierten Modulen. Keines davon ist universell überlegen. Die falsche Wahl zeigt sich meist dann, wenn ein Team ein Muster wählt, bevor Update-Frequenz, Ownership und Recovery-Anforderungen definiert wurden.
| Pattern | Komplexität | Speicherverbrauch | Bester Anwendungsfall |
|---|---|---|---|
| Lokaler Component-State | Niedrig | Niedrig | Bildschirm-spezifische Toggles, Entwürfe, Disclosure-Panels, temporäre Auswahl |
| Zentralisierter, leichtgewichtiger Store | Mittel | Mittel | Gemeinsame Session-Präferenzen, Theme, aktiver Workspace, UI-Koordination über Features hinweg |
| Event-Bus-Architektur | Mittel bis hoch | Variable | Lose Kopplung, Plugin-Benachrichtigungen, Native Bridge Events, isolierte Feature-Grenzen |
Local State sollte der Standard sein
Ein komponentenlokaler Wert hat einen kurzen Dependency-Pfad. Wenn ein Modal öffnet, eine Zeile expandiert oder ein Formularfeld sich ändert, kann das verantwortliche Feature aktualisiert werden, ohne die gesamte App zu benachrichtigen. Das reduziert ungewollte Kopplung und macht Unit-Tests direkter. Zudem begrenzt es den Speicherverbrauch, wenn mobile Bildschirme in den Standby gehen oder Desktop-Fenster lange offen bleiben.
Local State wird problematisch, wenn mehrere weit entfernte Features denselben Wert benötigen oder ein Workflow über Routengrenzen hinweggeht. In diesen Fällen ist es meist besser, den State in einen Feature-Store zu heben, statt ihn in einem globalen Singleton zu speichern. Ein kleiner Store wie Zustand oder Pinia kann gezielte Selectors und explizite Actions bereitstellen, ohne dass jede Komponente auf jede Änderung reagieren muss.
Der Preis dafür ist Disziplin. Lightweight Stores sind schnell erstellt, weshalb Teams oft mit vielen überlappenden Stores und unklaren Zuständigkeiten enden. Benenne den Owner, definiere Mutations-Methoden und vermeide es, ein mutierbares Objekt zu exponieren, das jede Komponente einfach überschreiben kann.
Events sind nützlich, aber sie sind keine Datenbank
Ein Event Bus eignet sich gut für Benachrichtigungen wie „Native Share abgeschlossen“, „Fenster wurde aktiv“ oder „Background Task hat neue Daten erhalten“. Er ermöglicht die Kommunikation zwischen Plugins und Modulen, ohne dass diese sich gegenseitig importieren müssen. Als einzige Quelle für den Business State ist er jedoch ungeeignet, da Events flüchtig sind. Ein Subscriber, der pausiert, entladen oder zu spät registriert wurde, könnte die Nachricht verpassen.
Nutze Events, um Ereignisse anzukündigen, und lass das empfangende Modul dann seinen autoritativen Store oder die Data Layer abfragen. Halte Event-Namen spezifisch und die Payloads versioniert, falls sich native und Web code getrennt weiterentwickeln.
Für den breiteren architektonischen Kontext: Insights zur mobilen App-Entwicklung von Bridge Global sind hilfreich, wenn man gemeinsame code gegen plattformspezifisches Verhalten abwägt. Das Gleiche gilt für den App State: Teile Domain Rules, wenn diese stabil sind, aber isoliere Lifecycle-Adapter und native Integrationspunkte. Eine praktische Mobile App Architektur sollte diese Grenzen in der Ordnerstruktur und im Dependency Graph sichtbar machen.
Persistenz und Offline-First Synchronisation
Ein In-Memory Store ist kein dauerhafter State. Das Betriebssystem kann einen mobilen Prozess pausieren oder beenden, ein Desktop-User kann ein Fenster schließen oder die Netzwerkverbindung bricht während einer Mutation ab. Offline-First-Design beginnt mit der Entscheidung, was der User wiederherstellen muss, und wählt dann Storage- und Synchronisationsregeln basierend auf dieser Anforderung.
Baue einen dauerhaften Write Path
Ein zuverlässiger Workflow trennt das unmittelbare Nutzererlebnis von der Remote-Bestätigung:
- Zuerst lokal schreiben. Wende die Nutzeraktion auf eine lokale Datenbank oder einen durable Document Store an, damit die UI reagiert, ohne auf das Netzwerk zu warten.
- Die Mutation in eine Queue stellen. Speichere die Operation mit Entity-ID, Operationstyp, Payload, Erstellungskontext und Retry-Status. Eine reine In-Memory-Queue geht beim Prozessabbruch verloren.
- Einen ehrlichen Status anzeigen. Unterscheide zwischen lokal gespeichert, synchronisiert ausstehend, synchronisiert und fehlgeschlagen. Nutzer müssen wissen, ob eine Änderung auf dem Gerät dauerhaft ist oder remote bestätigt wurde.
- Synchronisieren, wenn die Bedingungen es zulassen. Reconnects, App-Foreground-Events oder geplante Background-Tasks können Retries auslösen. Der Sync-Worker sollte idempotent sein, da unterbrochene Requests erneut gesendet werden können.
- Konflikte gezielt lösen. Die Server-Response muss entscheiden, ob die lokale Operation akzeptiert, abgelehnt, gemergt wurde oder eine manuelle Prüfung erfordert.
SQLite ist eine praktische Wahl für relationale Datensätze und transaktionale Queues in Native-Build-Apps. IndexedDB eignet sich für Browser-basierten Speicher und Electron-Renderer code, sofern das Team Schema-Upgrades und Transaktionsgrenzen sorgfältig verwaltet. Halte die Serialisierung explizit. Persistiere Domain-Daten und Recovery-Metadaten, keine Component-Instanzen, Closures oder Referenzen auf native Objekte.
Die Konfliktstrategie ist eine Produktentscheidung
Last-write-wins ist einfach, kann aber legitime Änderungen verwerfen. Field-level merging funktioniert, wenn unabhängige Felder sicher kombiniert werden können. Domänenspezifische Regeln sind sicherer für Bestände, Genehmigungen, Finanzdaten oder klinische Workflows, bei denen ein automatischer Merge die Bedeutung verändern könnte. Einige Konflikte sollten die Synchronisation blockieren und den Nutzer zur Auswahl auffordern.
Die Sync-Layer sollte zudem trennen zwischen Read Reconciliation von Mutation Replay. Das Refetching von Serverdaten beweist nicht, dass eine gepufferte Mutation erfolgreich war, und das Replaying einer Mutation garantiert nicht, dass der resultierende Datensatz noch der aktuellen Server-Repräsentation entspricht. Speichere Server-Versionen oder entsprechende Validatoren, gib strukturierte Konflikt-Antworten zurück und behalte genügend Queue-Historie, um Fehler zu erklären.
Für den benutzerseitigen Teil dieses Designs: das Erstellen eines Offline-Screens in Vue, Angular oder React bietet ein wichtiges Interface-Konzept: Der Offline-Modus sollte ein sichtbarer App-Status sein und keine versteckte Ausnahme in der Konsole.
Das folgende Video kann die Implementierung von Offline-Verhalten und Synchronisation ergänzen:
Performance-Tuning und Teststrategien
Performance-Probleme beim State entstehen selten durch einen einzelnen langsamen Reducer. Sie entstehen, wenn zu viele Subscriptions unnötige Renders in nicht verwandten Komponenten auslösen, abgeleitete Werte (derived values) zu oft neu berechnet werden, große Objektgraphen im Speicher bleiben oder Synchronisationsaufgaben auf dem UI-Thread laufen. Miss die Ausbreitung der Updates, anstatt zu raten, welche Library am schnellsten ist.
Ein Benchmark aus dem Jahr 2026 mit einem Dashboard und 100 verbundenen Komponenten sowie 10.000 Iterationen erbrachte für MobX Werte von 0,3 ms bei einfachen Änderungen, 0,4 ms bei verschachtelten Änderungen und 0,6 ms bei abgeleiteten Änderungen, während Redux Toolkit 0,8 ms, 1,2 ms und 1,5 ms in den entsprechenden Tests erreichte. Derselbe Benchmark verzeichnete 2,8 MB für Zustand und 4,2 MB für Redux Toolkit im Speichervergleich. Dies sind benchmarkspezifische Beobachtungen und keine universellen Garantien für die Produktion, aber sie verdeutlichen, warum die Granularität der Subscriptions und die Update-Strategie entscheidend sind. Siehe den vergleichenden React State Management Benchmark für den Testkontext.
Update-Grenzen optimieren
Beginne mit Selectors. Eine Komponente sollte nur das kleinste sinnvolle Datenfragment abonnieren, nicht das gesamte Session-Objekt oder die API Response. Nutze Memoization für abgeleitete Daten bei rechenintensiven Operationen, aber memoize nicht reflexartig jeden primitiven Wert. Memoization erhöht zudem den Overhead für Retention und Vergleiche – führe also vorher und nachher ein Profiling durch.
Virtualisiere lange Listen, normalisiere Datensätze, wenn Updates einzelne Entitäten betreffen, und vermeide es, ein großes Root-Objekt bei einer kleinen Feldänderung komplett zu ersetzen. In Electron solltest du den Renderer-Speicher über lange Sessions beobachten, da Fenster oft viel länger aktiv bleiben als ein mobiler Screen. Vermeide in Capacitor synchrone Persistenz bei hoher Input-Frequenz. Nutze Debouncing für Entwürfe oder speichere gezielte Checkpoints, um sicherzustellen, dass bei einem Crash keine Daten verloren gehen, die das Produkt halten muss.
Eine mit Springer verknüpfte Studie ergab, dass die Änderung des State-Management-Ansatzes die Programmausführungszeit um durchschnittlich um 17 % über alle Testszenarien reduzierte, was die These stützt, dass weniger unnötige Synchronisation und Recomputation spürbare Runtime-Gewinne bringen. Das Ergebnis findet sich in der Studie zur Performance von State Management in Web-Apps, sollte jedoch nicht als garantierte Verbesserung für jeden Stack betrachtet werden.
Transitions testen, nicht nur Werte
Ein State-Test, der lediglich isLoading nach einem erfolgreichen Request prüft, übersieht die kritischen Pfade. Teste die Sequenz:
- Hydration: persistierte Daten werden geladen, ungültige Datensätze abgelehnt und Defaults nur für fehlende Felder genutzt.
- Unterbrechung: ein Request wird abgebrochen oder die App geht während einer Mutation in den Hintergrund.
- Replay: gequeuedte Operationen werden sicher wiederholt, ohne Server-Effekte zu duplizieren.
- Konflikt: der Server lehnt eine veraltete Version ab und das UI bietet eine lösbare Resolution an.
- Isolation: ein lokales UI-Update führt nicht dazu, dass unbeteiligte Features neu gerendert oder mutiert werden.
Nutze Mock-Adapter für den Server-State an der Network-Boundary und setze auf Integrationstests für komplette Workflows. Füge Instrumentation in der Entwicklung und in der CI hinzu, um unerwartete Subscriber-Counts, unbegrenzte Queues oder State-Transitions nach dem Unmount eines Features zu erkennen. Die wertvollste Test-Fixture ist oft eine realistische Lifecycle-Sequenz statt einer weiteren isolierten Reducer-Assertion. Nutze Leitfaden zur App-Performance-Optimierung wenn man diese Messwerte in einen wiederholbaren Release-Check verwandelt.
Plattformspezifische Hinweise für Capacitor und Electron
Eine Web-App kann davon ausgehen, dass ihr JavaScript-Prozess länger verfügbar bleibt als bei einer mobilen App. Capacitor und Electron durchbrechen diese Annahme auf unterschiedliche Weise. Capacitor bettet die Web-Schicht in einen mobilen Lifecycle ein, der von iOS oder Android verwaltet wird, während Electron einen Chromium-Renderer mit einem Desktop-Prozessmodell verbindet, bei dem Fenster unabhängig erscheinen und verschwinden können.
Capacitor erfordert Lifecycle-aware Hydration
Betrachte das Backgrounding als Chance für einen Checkpoint, nicht als Beweis dafür, dass der Prozess fortgesetzt wird. Bei einer Änderung des App-States kritische ausstehende Mutationen flushen, den aktuellen Sync-Cursor speichern und Ressourcen freigeben, die nicht aktiv bleiben sollten. Beim Wechsel in den Foreground das Verlorene rehydrieren, die Authentifizierung verifizieren, veraltete Serverdaten aktualisieren und Subscriptions erst neu starten, wenn der lokale Store bereit ist.
Der JavaScript-Store sollte nicht direkt die Internals nativer Plugins verwalten. Kamera-Sessions, Biometrie-Prompts, Push-Registrierungen, Filesystem-Handles und Background-Tasks unterliegen jeweils eigenen Plattform-Lifecycle-Regeln. Kapsle sie in Adaptern, die native Callbacks in Domain-Events oder Commands übersetzen. So kann der Store Zustände wie unavailable, requesting, active, failed oder completed abbilden, ohne ein natives Objekt zu halten, das nach einer Suspension ungültig wird.
Die Webview-Grenze macht zudem die Serialisierung wichtig. Übergib Plain Data über die Capacitor Bridge, validiere Plugin-Responses und versioniere Nachrichten, wenn ein live update mit verschiedenen Web-Bundles interagiert, die auf installierten nativen code laufen. Wie Capacitor Web und native code verbindet erklärt die Grenze, die diesen Adapter-Ansatz notwendig macht.
Electron benötigt Process Ownership
Der Main-Process von Electron sollte privilegierte Operationen und die dauerhafte Koordination übernehmen, während Renderer den view-spezifischen State verwalten. Nutze typisierte IPC-Commands für Aktionen wie das Lesen sicherer Settings, das Schreiben von Dateien oder die Fenster-Koordination. Gib nicht jedem Renderer breiten Filesystem-Zugriff und behandle ein an ein Fenster gesendetes Event nicht als dauerhaften Application Record.
Multi-Window-Apps brauchen ein explizites Synchronisationsmodell. Der Main-Prozess kann autoritative Updates verteilen, während jeder Renderer den lokalen Presentation State verwaltet. Wenn zwei Fenster denselben Datensatz bearbeiten, braucht die App Versionsprüfungen oder eine Conflict Policy – nicht nur ein Broadcast-Event. Ein geschlossenes Fenster muss seinen State beim erneuten Öffnen rekonstruieren können; deshalb müssen Main-Prozess oder Persistence Layer die Quelle für wiederherstellbare Daten bleiben.
Capacitor und Electron können Domain Models, API Clients, Queue-Formate und Reducer teilen. Sie müssen jedoch nicht zwingend dieselben Lifecycle code nutzen. Die stärkste Cross-Platform-Architektur nutzt ein gemeinsames State-Vokabular sowie plattformspezifische Adapter für Durability, Bridge und Recovery.
Migration zu einer modernen Hybrid-Architektur
Ein Legacy-Global-Store muss selten neu geschrieben werden. Er braucht eine Bestandsaufnahme und eine Abfolge sicherer Extraktionen. Migration klappt am besten, wenn jedes Feature jeweils eine State-Klasse verschieben kann, während der alte Store für unberührte Screens verfügbar bleibt.
Beginnen Sie mit Ownership, nicht mit Technologie
Erstelle einen State-Katalog für den bestehenden Store. Erfasse für jedes Feld die Quelle, die Consumer, Mutationspfade, Persistenzanforderungen und das Recovery-Verhalten. Markiere, ob es vom Server abgeleitet, von der Route abgeleitet, vom Formular verwaltet, feature-lokal oder geteilt ist. Diese Übung zeigt oft, dass der globale Store mehrere voneinander unabhängige Systeme hinter einem einzigen API verbirgt.
Verschiebe zuerst den Server-State. Ersetze manuell gespiegelte API Felder durch einen dedizierten Fetching- und Caching-Layer, der Request-Status, Invalidation, Retries und Revalidation verwaltet. Halte die Selectors vorübergehend kompatibel, damit bestehende Screens migrieren können, ohne alle Aufrufstellen gleichzeitig ändern zu müssen. Lösche die duplizierte Server-Kopie erst, wenn die neue Quelle die Integrationstests bestanden hat.
Gib als Nächstes den URL-State an den Router zurück. Suchfilter und ausgewählte Ressourcen sollten durch Route-Parameter oder Query-State auch nach Reloads oder beim Teilen erhalten bleiben. Entferne Synchronisationseffekte, die URL-Werte in einen Store kopieren und Store-Werte zurück in die URL schreiben. Solche Loops verursachen Race Conditions und machen den Browser-Verlauf unzuverlässig.
Feature-State schrittweise extrahieren
Verschiebe Modal-State, Wizard-Fortschritt und lokale Auswahl in die nächstgelegene Feature-Boundary. Wenn mehrere Komponenten den Wert benötigen, nutze einen Feature-Store mit einer schlanken Schnittstelle. Reserviere den verbleibenden globalen Store für Cross-Cutting Concerns wie Session-Policy, Theme, Berechtigungen oder einen explizit geteilten Workflow.
Nutze während der Transition einen Compatibility Layer. Dieser kann die neue Quelle lesen, während er die alte Selector-Struktur beibehält, sodass Features hinter Flags migriert werden können. Veröffentliche jede Extraktion unabhängig, überwache Error-Paths sowie das Hydration-Verhalten und behalte eine Rollback-Route bei, bis das neue Ownership-Modell stabil läuft.
Für Capacitor- und Electron-Teams kann Capgo signierte JavaScript-, CSS-, Konfigurations- und Asset-Bundles über gezielte Channels ausliefern – inklusive Rollout-Steuerung, Versionshistorie, Device-Logs, Adoption- und Failure-Metriken sowie automatischem Rollback-Schutz. So lässt sich ein Refactor des State-Managements inkrementell ausrollen, während native Änderungen weiterhin dem jeweiligen Plattform-Release-Prozess folgen. Der operative Vorteil liegt in der Kontrolle über die Migration, nicht darin, Tests oder die Kompatibilitätsplanung zu überspringen.
Best Practices und häufige Fehler, die man vermeiden sollte
Die State-Architektur scheitert, wenn Review-Fragen zu vage bleiben. Nutze diese Checks in Design-Reviews und Pull Requests:
- Benenne den Owner in code: Frage: „Welches Modul kann diesen Wert ändern und was in API erzwingt diese Grenze?“ Lehne einen Store ab, der nur hinzugefügt wurde, weil zwei Komponenten aktuell dasselbe Feld benötigen.
- Definiere den Recovery-Contract: Dokumentiere für jeden persistierten Wert, ob Reload, App-Restart, Logout oder Account-Switch ihn erhalten oder löschen. Ein Entwurfs-Invoice kann einen Restart überstehen, während ein ausgewähltes Workspace eine Revalidierung erfordern kann.
- Mache die Synchronisation beobachtbar: Logge Request-IDs, Versionen, Retry-Counts und Konflikt-Ergebnisse. Richte Alerts für wiederholte Retries oder Konflikte ein, bevor User fehlende Updates melden.
- Prüfe Commands, nicht das Objekt-Schema: Eine Mutation sollte ihre Business-Intention klarstellen, Inputs validieren und einen audit-freundlichen Action-Namen bieten. Direkte Writes, die diese Checks umgehen, gehören in das Code-Review.
- Teste feindselige Sequenzen: Führe Tests für Hydration-Races bei der Navigation, abgebrochene Writes mit anschließendem Retry, doppelte Zustellung, Offline-Edits aus zwei Fenstern und Logouts während eines Pending-Requests durch.
- Prüfe den Löschpfad: Eine Migration ist unvollständig, wenn ein alter Selector, Persistence-Adapter oder Event-Listener noch in den alten Store schreibt. Füge einen Test hinzu, der fehlschlägt, wenn beide Quellen dasselbe Feld updaten.
Eine typische PR-Frage ist: „Was passiert, wenn dieser Prozess nach dem Write-Start, aber vor der Bestätigung abbricht?“ Die Antwort sollte Durable Data, Retry-Ownership, Deduplizierung und den sichtbaren Error-State für den User klären.
Capgo hilft CapacitorJS- und Electron-Teams, JavaScript-, CSS-, Config- und Asset-Updates über gezielte Channels auszurollen – mit signierten Bundles, Rollout-Controls, Device-Logs und Rollback-Schutz. Nutze Capgo um Refactors am State-Management und Recovery-Fixes inkrementell auszuliefern und diese anschließend mit Lifecycle- und Sync-Tests zu validieren.
