Utmaningar

Nedan finns sex frågor om progressiva webbapplikationer. Frågorna bygger på veckans artiklar Progressiva webbapplikationer, Service workers och Offline med Cache API.

Varje fråga har ett antal alternativ att välja bland. Klicka på “Visa lösning” för att se svaret och förklaringen.

Om du är osäker kan du alltid testa själv med npm run build och npm run serve, och följa vad som händer under Application i webbläsarens utvecklarverktyg, eller ta upp frågan på en handledning.

Fråga 15-01: Progressiv?

Vad betyder progressiv i progressiv webbapplikation?

Att applikationen laddas in bit för bit medan användaren använder den.
Att applikationen fungerar som en vanlig webbsida i alla webbläsare, och blir bättre där webbläsaren stöder mer.
Att applikationen uppdateras automatiskt till senaste versionen.
Att applikationen bara fungerar i de nyaste webbläsarna.

Tips

Lösningsförslag

Svaret är alternativ 2. Ordet kommer från progressive enhancement, progressiv förbättring. En PWA ska fungera som en vanlig webbsida överallt, och bli installerbar och fungera offline där webbläsaren klarar det. Därför kontrollerar du stödet innan du använder ett API.

Alternativ 1 beskriver snarare lazy loading, som du möter i kursvecka 16. Alternativ 4 är motsatsen till vad begreppet står för.

Fråga 15-02: Installerbar

Vilket av följande manifest gör applikationen installerbar i Chrome? Sidan visas från http://localhost:4173.

name, start_url, display: "browser" och ikoner i 192 och 512 pixlar.
name, start_url, display: "standalone" och en ikon i 192 pixlar.
short_name, start_url, display: "standalone" och ikoner i 192 och 512 pixlar.
Inget av dem, eftersom sidan inte visas över HTTPS.

Tips

Lösningsförslag

Svaret är alternativ 3. Chrome kräver name eller short_name, start_url, display satt till standalone, fullscreen eller minimal-ui, och ikoner i både 192 och 512 pixlar.

Alternativ 1 har display: "browser", som öppnar en vanlig flik och inte räcker för installation. Alternativ 2 saknar ikonen i 512 pixlar. Alternativ 4 stämmer inte: localhost räknas som en säker kontext, precis som HTTPS.

Fråga 15-03: Räckvidd

Service workern ligger i public/js/sw.js i ett Vite-projekt och registreras med navigator.serviceWorker.register('./js/sw.js') från index.html. Applikationen fungerar inte offline. Varför?

Vite ger filen en hash i namnet vid bygget, så webbläsaren hittar den inte.
Service workerns räckvidd blir /js/, och dokumentet på / ligger utanför.
En service worker får inte ligga i en undermapp.
Registreringen måste ske i sw.js, inte från sidan.

Tips

Lösningsförslag

Svaret är alternativ 2. Räckvidden är som standard mappen där filen ligger, här /js/. Dokumentet / ligger utanför, och förfrågningarna från det passerar aldrig service workern. Registreringen lyckas ändå, så felet märks först när applikationen inte fungerar offline.

Alternativ 1 stämmer inte: filer i public/ kopieras som de är, utan hash. Alternativ 3 är för starkt, en service worker får ligga i en undermapp, men styr då bara sidor där. Lägg den i public/sw.js så att den styr hela applikationen.

Fråga 15-04: Den nya versionen

Du ändrar i public/sw.js, kör npm run build och laddar om sidan på localhost:4173 två gånger. Under Application → Service workers står den nya versionen som waiting. Vad behöver hända för att den ska ta över?

Inget, den tar över av sig själv efter en stund.
Du måste ladda om sidan med Shift nedtryckt.
Alla flikar som använder den gamla versionen måste stängas, eller så anropas skipWaiting().
Du måste byta namn på cachen i sw.js.

Tips

Lösningsförslag

Svaret är alternativ 3. En ny version väntar så länge någon flik använder den gamla, och en vanlig omladdning släpper aldrig den gamla. Stäng alla flikar med applikationen, klicka på skipWaiting i utvecklarverktygen eller låt service workern anropa self.skipWaiting(). Under utveckling är Update on reload enklast.

En omladdning med Shift går förbi service workern för just den laddningen, men aktiverar inte den nya versionen. Cachens namn styr vilken cache som används, inte vilken version av service workern som är aktiv.

Fråga 15-05: Första besöket

En användare öppnar ditt PWD för första gången och service workern installeras och aktiveras. Användaren stänger av nätverket direkt och laddar om sidan. Skrivbordet visas inte. Service workern använder network first och cachar i förväg bara ./ och manifestet. Varför fungerar det inte?

Service workern aktiveras inte förrän nästa dag.
Skripten och stilmallen under /assets/ hämtades förbi service workern vid första besöket och finns inte i cachen.
Network first fungerar inte offline.
Cache API sparar inget förrän användaren har installerat applikationen.

Tips

Lösningsförslag

Svaret är alternativ 2. Vid första besöket styr service workern inte sidan, och alla filer hämtas förbi den. Dokumentet finns i cachen eftersom det cachades i förväg, men det pekar på skript och en stilmall under /assets/ som inte gör det. Från och med andra besöket hämtas allt genom service workern, och då fungerar applikationen offline.

Filerna under /assets/ kan inte cachas i förväg för hand, eftersom Vite bestämmer deras namn vid bygget. Verktyg som vite-plugin-pwa skriver listan åt dig om första besöket måste räcka.

Fråga 15-06: Strategi

Vilken kombination av strategier passar för en applikation byggd med Vite?

Cache first för allt, eftersom det är snabbast.
Network first för allt, eftersom det alltid ger den senaste versionen.
Network first för dokumentet, cache first för filerna under /assets/.
Cache first för dokumentet, network first för filerna under /assets/.

Tips

Lösningsförslag

Svaret är alternativ 3. Dokumentet, index.html, har alltid samma adress men pekar på nya filer efter varje bygge, och behöver network first för att användaren ska få den senaste versionen. Filerna under /assets/ har en hash av innehållet i namnet och ändras aldrig under samma adress, så för dem är cache first säkert och snabbare.

Alternativ 2 fungerar också, bara lite långsammare. Alternativ 1 låser användarna vid den version som cachades först, och alternativ 4 gör samma sak med dokumentet, som är filen som avgör vilken version som körs.