”Sparad” ska betyda att appen fått bekräftelse på den aktuella texten från den plats där anteckningen ska sparas. Ett påbörjat försök räcker inte. Om du skriver vidare medan appen sparar får ett äldre svar inte markera din nya text som sparad.
Bestäm vilken text som är bekräftad
Använd en privat testanteckning med påhittat innehåll. Skriv ”Testanteckning A: ta med den blå mappen”. Det är din första version. Lägg sedan till ”och den röda pennan”. Nu är innehållet nytt, även om appen fortfarande väntar på svar för den första meningen. Den skillnaden är artikelns kärna: bekräftelsen måste höra till texten som faktiskt visas.
Här beställer du ett beteende och ett facit, inte en databaslösning. Om appen ännu inte har någon beständig plats för anteckningen börjar du med guiden om data och inloggning. Lovables Cloud-dokumentation beskriver en backend med bland annat databas och inloggning. Det är produktens möjligheter; dokumentationen visar inte att just din anteckningsfunktion har korrekt autosparande.
Fyra tillstånd med tydlig innebörd
Låt beskeden finnas som text nära anteckningen; färgen ska vara ett stöd. Be också att statusändringarna kan förmedlas av skärmläsare utan att skrivfokus flyttas. W3C:s vägledning om statusmeddelanden förklarar just förmedling av sådana ändringar till hjälpmedel. Den kräver inte att du bygger autosparande och ger inget löfte om att data behålls.
Kopiera beställningen och byt bara funktionens namn
Beställningen gäller en användare som redigerar en privat anteckning i ett öppet fönster. Låt verktyget förklara eventuella begränsningar innan du betraktar funktionen som färdig. En ruta som säger ”Sparad” trots att innehållet är okänt klarar inte kravet.
Autospara innehållet i [min privata anteckning]. Visa tillstånden Ändrad, Sparar, Sparad och Misslyckades som tydliga textbesked. Sparad får visas först när den aktuella texten har bekräftats från den plats där anteckningen ska sparas. Ett startat försök räcker inte. Om jag skriver vidare får ett sent svar för en äldre version inte markera den nyare texten som sparad eller ersätta den i redigeraren. Den nyaste texten ska också vara den som finns efter bekräftad sparning och omladdning; äldre försök får inte skriva tillbaka en äldre version. Vid fel ska min aktuella text vara kvar i det öppna fönstret och gå att markera och kopiera. Visa ett tydligt fel och Försök igen. Försök igen ska spara den aktuella texten i samma anteckning, utan en extra anteckning. Om utfallet är okänt ska appen inte påstå Sparad. Statusändringar ska kunna förmedlas med skärmläsare utan att flytta skrivfokus. Beställningen omfattar inte återställning av osparad text efter omladdning, stängd flik eller avstängd enhet. Beskriv separat vad som krävs för det. Sammanfogning mellan användare ingår inte. Visa hur jag provar normal sparning, tappad anslutning, snabba ändringar och Försök igen med en påhittad testanteckning. För ett kontrollerat test ska ett äldre sparförsök kunna fördröjas så att dess svar kommer efter en nyare ändring. Ändra inget annat.
Prov 1: vänta på beskedet och ladda sedan om
Skapa anteckningen och skriv testmeningen om den blå mappen. Vänta tills appen visar ”Sparad”. Ladda då om sidan och öppna samma anteckning. Facit är den exakta meningen, inklusive dess sista ord. Lägg till den röda pennan, invänta ett nytt ”Sparad” och gör om provet. Du ska fortfarande ha en anteckning, nu med båda delarna.
Skriv upp beskedet före omladdning och texten efteråt. Om den andra meningen saknas är det ett konkret fel även om den första finns kvar. Omladdningen kontrollerar det observerbara utfallet för denna anteckning; den är inget bevis för alla felvägar eller all framtida lagring. Ladda inte om med osparad text i nästa prov.
Prov 2: bryt anslutningen och behåll utkastet
När första provet fungerar stänger du av nätanslutningen på testenheten. Låt redigeraren vara öppen. Lägg till ”Test B: detta skrevs utan anslutning”. Förväntat utfall är att appen visar att texten inte är bekräftat sparad, och efter ett misslyckat försök visar felet. Den nya meningen ska finnas kvar och gå att kopiera. Ta en kopia till ett separat dokument innan du gör något som kan stänga sidan.
Slå på anslutningen igen och tryck på ”Försök igen” om appen inte gör ett tydligt nytt försök själv. Vänta på bekräftelsen. Ladda därefter om och kontrollera Test B. Kontrollera också listan: samma anteckning ska ha uppdaterats, utan en extra post. Om du kan prova ett nytt försök medan ett tidigare svar är fördröjt, kontrollera även den vägen. Ett avbrott kan lämna utfallet oklart för dig; provet ska därför även kontrollera dubbletter, inte bara grönt besked.
Prov 3: låt ett gammalt svar komma sent
Be verktyget ordna det kontrollerade fördröjningsprovet i en testmiljö. Skriv ”Version C: blå”, låt ett sparförsök börja och ändra direkt till ”Version D: röd”. När svaret för C kommer får D varken försvinna eller få ”Sparad” på grund av C:s bekräftelse. Facit är att beskedet avser D först när D är bekräftad. Efter detta besked och omladdning ska D finnas kvar.
Du kan själv göra ett första snabbprov genom att skriva, pausa kort och skriva vidare flera gånger. Det kan avslöja en felaktig status. Det bevisar däremot inte att svaren kom i omvänd ordning. Redovisa därför separat om du bara skrev snabbt eller om testmiljön verkligen lät ett äldre svar komma sent. Be om en demonstration med versionsorden synliga, så att du kan följa utfallet utan kod.
Här är det samma användares ändringar som ska hållas isär. Om två personer redigerar samma post behöver du dessutom besluta om krockar. Det behandlas i artikeln om två användare som gör samma sak samtidigt. Ett godkänt snabbprov för en användare avgör inte den frågan.
Vad ”texten finns kvar här” faktiskt lovar
Att behålla texten i ett öppet fönster är ett mindre krav än att få tillbaka den efter att fliken stängts. Vill du lova offlineåterställning behöver du en separat beställning om var utkast lagras, hur länge de sparas, hur de kopplas till rätt användare och när de tas bort. Prova sedan just omladdning och återöppning med osparad testtext. Skriv inget sådant löfte i appen innan lösningen är byggd och kontrollerad.
En varning när du lämnar sidan är ett komplement, inte ditt återställningsprov. MDN dokumenterar att beforeunload inte utlöses tillförlitligt, särskilt på mobil, exempelvis när användaren byter app och senare stänger webbläsaren från apphanteraren. Utgå därför inte från att en dialog hinner rädda texten. Vad listan ska visa innan någon anteckning finns behandlas i artikeln om appens tomma lägen.
Rapportera felet så att det går att upprepa
Spara provet med datum, testenhet, webbläsare och vilken testmiljö du använde. Ange anteckningens testnamn, texten före och efter ändringen samt exakt vilket besked som visades. Beskriv om anslutningen var avstängd och om ett äldre svar medvetet fördröjdes. Bifoga bara påhittad testtext.
Miljö och datum: [testmiljö, enhet, webbläsare, datum] Testanteckning: [namn] Steg: [vad jag skrev och gjorde, i ordning] Status jag såg: [ordagrant besked och när det visades] Förväntat: [vilken version ska vara bekräftad eller kvar] Faktiskt: [vad stod i redigeraren och efter eventuell omladdning] Anslutning/fördröjning: [hur felet framkallades] Antal anteckningar efter nytt försök: [antal] Upprepning: [vilka steg gav samma fel igen]
Godkänn funktionen när de tre proven ger sina facit och appens ord stämmer med dess beteende. Beställningarna och testfaciten ovan är föreslagna acceptanskrav, inte resultat från en körd app. Primärkällorna kontrollerades 13 oktober 2026.
Källor och avgränsning
- W3C: Status Messages – stöd för tillgängliga besked i avsnittet om tillstånd.
- MDN: beforeunload – begränsningen för sidlämningsvarningar i avsnittet om återställning.
- Lovable Cloud – produktens backendmöjligheter i avsnittet om bekräftad text; inget belägg för den egna appens autosparande.