A lecke végére meg tudod mondani, mi a service worker, mit tud és mit nem, miben különbözik a Cache API az IndexedDB-től, és pontosan meg tudod fogalmazni, mi működik egy alkalmazásban offline.
Miért van szükség háttérkomponensre?
A webalkalmazás hálózata megszakadhat: vonaton, liftben, gyenge lefedettségnél. A hagyományos oldal ilyenkor „nincs kapcsolat” hibát mutat. Ha viszont az alkalmazás előre eltárolta a szükséges erőforrásokat, és van egy komponens, amely a hálózati kérésekre helyből is válaszolhat, bizonyos dolgok hálózat nélkül is működhetnek. Ezt a feladatot látja el a service worker.
A kurzusanyag útközben
Egy hallgató vonaton megnyitná a korábban látott kurzusleírást, de a kapcsolat megszakad. Ha az alkalmazás előre eltárolta a szükséges HTML-t, stílust és más erőforrásokat, a service worker bizonyos kérésekre ezekből válaszolhat. A hallgató így olvashatja a korábban elérhetővé tett anyagot. A friss férőhelyszámot vagy az új jelentkezést viszont hálózat és szerveroldali döntés nélkül nem lehet megbízhatóan véglegesnek tekinteni.
flowchart TD
O[Oldal erőforrást kér] --> W[Service worker]
W -->|van megfelelő helyi válasz| C[Cache]
W -->|hálózat szükséges| N[Szerver]
C --> O
N --> O
Az ábra egy lehetséges működést mutat. A service worker nem minden oldal minden kérését irányítja, és a tényleges útvonalat az alkalmazás gyorsítótárazási stratégiája határozza meg.
Mi a service worker?
Az MDN szerint a service worker egy eseményvezérelt komponens, amely egy eredethez és útvonalhoz van regisztrálva, és proxyként működik a webalkalmazás, a böngésző és a hálózat között. Tulajdonságai:
Elkülönült szál: nem fér hozzá közvetlenül a DOM-hoz; a látható felületet továbbra is az oldal kezeli.
Eseményvezérelt: olyan eseményekre reagál, mint az install, activate és a fetch (egy kérés elfogása és az arra adott válasz meghatározása).
Hatókör (scope): az eredet egészére vagy egy részére vonatkozik, amelyet regisztrációkor lehet megadni.
Biztonságos környezet: HTTPS-t igényel (a localhost kivétel), mert egy ilyen komponens elfoghatja a kéréseket.
Életciklus: az install eseményben jellemzően a gyorsítótárat töltik fel; az új verzió „várakozó” állapotban telepítődik, és csak akkor aktiválódik, ha már nincs olyan oldal, amelyet a régi verzió vezérel; az activate esemény a régi gyorsítótárak takarítására való.
Mivel az életciklus külön, egy új alkalmazásverzió és a régi gyorsítótári tartalom együtt könnyen hibát okozhat, ha nincs következetes frissítési terv.
Egy rövid vázlat a fetch eseményről (szemléltető, nem futtatott, mert böngészőt és HTTPS-t vagy localhost-ot igényel):
A mintában a service worker először a gyorsítótárban keres, és csak ha nem talál, fordul a hálózathoz.
Cache, helyi adat és offline művelet
A Cache API kérés–válasz párokat tárol. Az MDN szerint a tételek nem frissülnek és nem járnak le maguktól: a szkriptnek (például a service workernek) kell a frissítést és a törlést végeznie, jellemzően verziózott cache-nevekkel. A böngésző a tárhely szűkössége esetén az eredet adatait törölheti. Az IndexedDB ezzel szemben strukturált alkalmazási adatot kezel (3.6), például egy félbehagyott jegyzetet. A két tároló más célra való:
Tároló
Mit tárol?
Tipikus offline használat
Cache API
HTTP-válaszok (HTML, CSS, JavaScript, képek)
Offline olvasható oldalak
IndexedDB
Strukturált alkalmazási adat
Offline szerkesztett jegyzet, művelet-sor
Az offline végzett módosítás szerverre továbbítása külön szinkronizálási probléma: ha a hallgató offline jelentkezett, a jelentkezést a hálózat visszatértekor a szervernek kell elfogadnia vagy elutasítania (betelt, határidő lejárt), és erről a felhasználót értesíteni kell.
Nem azonos az SPA-val
A service worker többoldalas és egyoldalas webhelyhez is kapcsolható. Az SPA a navigáció és felület modellje (6.1); a service worker a kérések és háttérfeladatok egyik böngészős eszköze. Egy SPA nem működik automatikusan offline, és egy MPA is kínálhat offline olvasható oldalakat.
Végigvezetett példa: mi működik offline a Kurzuspontban?
Funkció
Offline?
Indok
Már megnyitott kurzusleírás olvasása
igen
A leírás és az erőforrásai a cache-ben vannak.
Szabad helyek száma
nem megbízhatóan
Élő adat; a cache régi értéket mutathat. A felület jelzi: „utolsó frissítés: ...”.
Service worker és offline működés
Célok
A lecke végére meg tudod mondani, mi a service worker, mit tud és mit nem, miben különbözik a Cache API az IndexedDB-től, és pontosan meg tudod fogalmazni, mi működik egy alkalmazásban offline.
Miért van szükség háttérkomponensre?
A webalkalmazás hálózata megszakadhat: vonaton, liftben, gyenge lefedettségnél. A hagyományos oldal ilyenkor „nincs kapcsolat” hibát mutat. Ha viszont az alkalmazás előre eltárolta a szükséges erőforrásokat, és van egy komponens, amely a hálózati kérésekre helyből is válaszolhat, bizonyos dolgok hálózat nélkül is működhetnek. Ezt a feladatot látja el a service worker.
A kurzusanyag útközben
Egy hallgató vonaton megnyitná a korábban látott kurzusleírást, de a kapcsolat megszakad. Ha az alkalmazás előre eltárolta a szükséges HTML-t, stílust és más erőforrásokat, a service worker bizonyos kérésekre ezekből válaszolhat. A hallgató így olvashatja a korábban elérhetővé tett anyagot. A friss férőhelyszámot vagy az új jelentkezést viszont hálózat és szerveroldali döntés nélkül nem lehet megbízhatóan véglegesnek tekinteni.
flowchart TD O[Oldal erőforrást kér] --> W[Service worker] W -->|van megfelelő helyi válasz| C[Cache] W -->|hálózat szükséges| N[Szerver] C --> O N --> OAz ábra egy lehetséges működést mutat. A service worker nem minden oldal minden kérését irányítja, és a tényleges útvonalat az alkalmazás gyorsítótárazási stratégiája határozza meg.
Mi a service worker?
Az MDN szerint a service worker egy eseményvezérelt komponens, amely egy eredethez és útvonalhoz van regisztrálva, és proxyként működik a webalkalmazás, a böngésző és a hálózat között. Tulajdonságai:
install,activateés afetch(egy kérés elfogása és az arra adott válasz meghatározása).localhostkivétel), mert egy ilyen komponens elfoghatja a kéréseket.installeseményben jellemzően a gyorsítótárat töltik fel; az új verzió „várakozó” állapotban telepítődik, és csak akkor aktiválódik, ha már nincs olyan oldal, amelyet a régi verzió vezérel; azactivateesemény a régi gyorsítótárak takarítására való.Mivel az életciklus külön, egy új alkalmazásverzió és a régi gyorsítótári tartalom együtt könnyen hibát okozhat, ha nincs következetes frissítési terv.
Egy rövid vázlat a
fetcheseményről (szemléltető, nem futtatott, mert böngészőt és HTTPS-t vagylocalhost-ot igényel):self.addEventListener("fetch", (esemeny) => { esemeny.respondWith( caches.match(esemeny.request).then((talalat) => talalat || fetch(esemeny.request)) ); });A mintában a service worker először a gyorsítótárban keres, és csak ha nem talál, fordul a hálózathoz.
Cache, helyi adat és offline művelet
A Cache API kérés–válasz párokat tárol. Az MDN szerint a tételek nem frissülnek és nem járnak le maguktól: a szkriptnek (például a service workernek) kell a frissítést és a törlést végeznie, jellemzően verziózott cache-nevekkel. A böngésző a tárhely szűkössége esetén az eredet adatait törölheti. Az IndexedDB ezzel szemben strukturált alkalmazási adatot kezel (3.6), például egy félbehagyott jegyzetet. A két tároló más célra való:
Az offline végzett módosítás szerverre továbbítása külön szinkronizálási probléma: ha a hallgató offline jelentkezett, a jelentkezést a hálózat visszatértekor a szervernek kell elfogadnia vagy elutasítania (betelt, határidő lejárt), és erről a felhasználót értesíteni kell.
Nem azonos az SPA-val
A service worker többoldalas és egyoldalas webhelyhez is kapcsolható. Az SPA a navigáció és felület modellje (6.1); a service worker a kérések és háttérfeladatok egyik böngészős eszköze. Egy SPA nem működik automatikusan offline, és egy MPA is kínálhat offline olvasható oldalakat.
Végigvezetett példa: mi működik offline a Kurzuspontban?
Ez a táblázat egyúttal az offline-határ megnevezése: pontosan tudja a felhasználó, mi működik és mi nem.
Gyakori tévhitek
Röviden
localhost) kell hozzá, és külön életciklusa van.Ellenőrző kérdések
Tanulási források