Web-Anwendungen
Formulare beim Tabwechsel: Entwurf, Wiederherstellung und Versand trennen
Nach einem Tabwechsel wieder sichtbarer Text ist hilfreich. Er beweist aber weder einen dauerhaft gespeicherten Entwurf noch eine vom Server angenommene Anfrage. Entwerfen Sie diese Zustände und ihre Meldungen ausdrücklich.
Dieser Leitfaden ist evergreen. MDN beschreibt visibilitychange und den Übergang zu hidden als wichtigen letzten beobachtbaren Lebenszykluspunkt. Das Ereignis meldet Sichtbarkeit; es bestätigt keinen erfolgreichen Speichervorgang und keinen abgeschlossenen Versand. (MDN Web Docs)
Zuerst ein verständliches Zustandsmodell
Eine Oberfläche sollte nicht denselben Hinweis für drei unterschiedliche Dinge verwenden. «Entwurf in diesem Browser», «Entwurf auf dem Server gespeichert» und «Anfrage angenommen» benötigen jeweils einen eigenen Nachweis. Wo keine Speicherung vorgesehen ist, muss der Nutzer das ebenfalls erkennen können.
| Zustand | Benötigter Nachweis | Passende Aussage an den Nutzer |
|---|---|---|
| Nur sichtbare Eingabe | Wert befindet sich in der aktuellen Oberfläche | Noch nicht gespeichert oder gesendet |
| Wiederherstellbarer Entwurf | Das vereinbarte Speicherverfahren hat den Entwurf bestätigt | Entwurf am benannten Ort gesichert |
| Übermittlung unklar | Anfrage wurde begonnen, Bestätigung fehlt | Ausgang offen; Status prüfen |
| Anfrage angenommen | Server bestätigt den definierten Geschäftsvorgang | Angenommen, mit zugehöriger Referenz |
Die Rückkehr im Browser ist ein eigener Testfall
bfcache kann eine Seite aus dem Speicher samt angehaltenem JavaScript wiederherstellen. pageshow.persisted kennzeichnet eine solche Rückkehr; pagehide.persisted beweist nur eine beabsichtigte Aufnahme. Eine wieder sichtbare Oberfläche ist deshalb nicht automatisch ein frischer Serverabruf. (web.dev / Chrome team)
Prüfen Sie bei der Rückkehr, ob ein vorhandener Entwurf noch zu Version und Status des Geschäftsfalls passt. Denken Sie etwa an eine Bestellung, die in einem anderen Fenster bearbeitet wurde. Ein guter Wiederherstellungsdialog verhindert, dass veralteter Text unbemerkt einen inzwischen bestätigten Zustand überschreibt.
Vier gezielte Versuche mit erfundenen Eingaben
Die folgende Matrix ist ein Vorschlag und wurde hier nicht ausgeführt. Verwenden Sie eine harmlose Testkennung und fiktive Werte. Halten Sie Browser, Version, Gerät und die gewählte Speicherpolitik fest, damit eine Beobachtung später wiederholt werden kann.
- Tab in den Hintergrund legen und zurückkehren: Bleiben Eingaben und sichtbarer Speicherstatus konsistent?
- Auf einem Mobilgerät zu einer anderen App wechseln und später zurückkehren: Entspricht der wiederhergestellte Zustand der zugesagten Speicherung?
- Zu einer anderen Seite navigieren und Zurück verwenden: Wird eine Wiederherstellung erkannt und der Geschäftsstatus bei Bedarf neu geprüft?
- Ein Verwerfen beziehungsweise erneutes Laden im erlaubten Testumfeld untersuchen: Ist der Entwurf tatsächlich wieder auffindbar oder war er nur im Speicher der alten Seite?
Die Page-Lifecycle-Dokumentation erklärt, warum Terminierungsereignisse wie unload unzuverlässig sind und Speicherentscheidungen früher fallen sollten. freeze/resume und Discard-Erkennung haben eigene Kompatibilitätsgrenzen. Es wäre falsch, aus einem Chrome-Test ein identisches Verhalten aller Browser abzuleiten. (Chrome for Developers / Philip Walton)
Speicherung braucht eine bewusste Datenentscheidung
Wählen Sie nicht allein aus Bequemlichkeit einen Browser-Speicher. Entscheiden Sie zunächst, welche Inhalte lokal liegen dürfen, wie lange und unter welcher Benutzerzuordnung. Auf gemeinsam genutzten Geräten kann ein wiederherstellbarer Entwurf unerwünscht sein. Ein serverseitiges Verfahren wiederum benötigt passende Identität, Rechte und Löschregeln.
Dokumentieren Sie auch, wann ein Entwurf ungültig wird und wann die Oberfläche ihn löschen oder zurückhalten soll. Ein Sichtbarkeitsereignis kann eine Aktion anstossen; es ist keine Garantie, dass asynchrone Arbeit vor einem Prozessabbruch fertig wird. Die Abnahme sollte daher die zugesagte Wiederherstellung prüfen und nicht bloss den registrierten Event-Handler.
Einreichung und Kosten gesondert behandeln
Bei einer unterbrochenen Übermittlung braucht die Anwendung eine Möglichkeit, den Ausgang abzuklären. Ein erneuter Klick darf nicht aus einem unklaren Zustand blind eine zweite Geschäftswirkung machen. Die Referenz des angenommenen Vorgangs ist dafür hilfreicher als ein zurückgesetztes Formular.
Die beschriebenen Browsermechanismen verlangen keine neue kostenpflichtige Plattform. Implementierung, Tests, gegebenenfalls Serverspeicher und Betrieb bleiben jedoch Aufwand. Diese Anleitung ändert keine bestehende Speicherpolitik: Insbesondere bleiben Werkzeuge, die ausdrücklich nicht speichern, dadurch nicht plötzlich persistent. Der nächste Schritt ist ein vereinbartes Zustandsmodell und ein Testprotokoll mit tatsächlichen Beobachtungen.
Quellen
- Document: visibilitychange event - Web APIs | MDN — MDN Web Docs
- Page Lifecycle API | Web Platform | Chrome for Developers — Chrome for Developers / Philip Walton · 2023-12-01
- Back/forward cache | Articles | web.dev — web.dev / Chrome team · 2023-05-25