Offline först (offline-first)

Rita först, hämta sen

Det som kännetecknar en offline först-app är att ingenting väntar på nätet för att ritas ut. Layout, navigering och statiskt innehåll visas direkt, och levande data fylls i efteråt. En app som väntar på ett databassvar innan den ritar något visar en tom skärm offline, hur bra cachningen än är.

Delarna som får det att fungera:

1. En service worker som serverar appskalet, formgivningen och redan visade bilder från cachen.
2. Lokal lagring av själva datan – localStorage för små mängder, IndexedDB för allt som är strukturerat eller stort.
3. Ett tydligt uppkopplingsläge i gränssnittet. navigator.onLine plus händelserna online och offline räcker för en ärlig banner. Användare accepterar "visar din senast sparade vy" betydligt bättre än en snurra som aldrig blir klar.
4. Fel per funktion, inte per app. Ett misslyckat anrop ska släcka en panel, inte hela sidan.

Skrivningarna är den svåra delen

Att läsa offline är ett cachningsproblem och i stort sett löst. Att skriva offline är ett problem i distribuerade system och är det inte. Så fort användare får skapa poster utan uppkoppling behöver du en kö som överlever en omladdning, omförsök som inte dubblerar poster om det första försöket faktiskt gick fram, och en regel för vad som händer när samma post ändrats på en annan enhet under tiden.

Det är därför så många "offline"-appar bara är offline för läsning, och det är fullt ärligt att leverera.

Missuppfattningen

Att cacha sidor förväxlas ofta med att vara offlinekapabel. Det är skilda saker: ett cachat skal betyder att appen öppnas, inte att den fungerar. Allt som är levande misslyckas fortfarande.

Publicerade NorthernGo-appar (subdomän eller egen domän) köar save() och delete() i SDK:n när det saknas nät, och get() returnerar senast lyckade lista plus väntande poster (märkta _pending: true). Inloggning, betalning, e-post och AI kräver fortfarande uppkoppling. Offlineguiden går igenom gränssnittet med två tillstånd.