Hogyan lehet az alkalmazást offline módban működtetni a JavaScript segítségével

A mai világban a kapcsolódás mobilabbá tett minket, mint valaha, ami (paradox módon) néha offline állapotba hoz minket: amikor repülőgép üzemmódban vagyunk, rossz a kapcsolatunk, nincs több adatunk, metrón vagyunk ... stb.

A mobilitás második hatása a nehéz weboldalak lassú betöltése: az Amazon megállapította, hogy csupán 100 milliszekundumnyi extra betöltési idő kerül nekik az eladások 1% -ába.

Ezekben a helyzetekben szeretnénk offline hozzáférést biztosítani a tartalmainkhoz. Ezért léteznek olyan eszközök, mint az Instapaper és a Pocket. A Spotify és a Netflix lehetővé teszi a média offline használatra történő letöltését is.

Könnyen beláthatjuk, hogy van igény erre a szolgáltatásra, és hogy ez milyen előnyökkel járhat vállalkozása számára.

Itt az ideje, hogy az internet elérhetővé váljon.

Szerencsére a cél eléréséhez már nem kell natív alkalmazásokat építeni. Az új szolgáltató munkatársaknak és a Cache API szolgáltatásainak köszönhetően offline weboldalt hozhatunk létre a JavaScript erejével .

Mi az a szolgáltató munkavállaló (SW)?

A kiszolgáló munkatársak olyan JavaScript kódok, amelyek a webhely hátterében futnak, még akkor is, ha az oldal bezárt. Offline használat esetén az egyik céljuk a hálózati kérések vagy képek tárolása a böngésző gyorsítótárában.

A BETC ügynökség a whentheinternetisdown.com nevű demo weboldalt készített a Bouygues francia távközlési vállalat számára. Csak offline módban működik, és mágikusnak érzi magát. Menj, próbáld ki :)

A gyorsítótár teszi a webhely varázslatát: 3 hét, 1 hónap, 1 év múlva visszatérhet, még mindig kapcsolat nélkül, és hozzáférhet az összes tartalomhoz. - Maxime Huygue, a BETC Digital Studio vezetője

Ok, ez klassz, akkor mondd meg, hogyan kell csinálni.

Oké, kezdjük néhány előfeltétellel:

  • Az SW-k használatához engedélyeznie kell a https-t a webhelyén.
  • Meg kell értenie a JavaScript ígéreteinek működését.
  • Az SW-k minden modern böngészőben működnek, az IE barátunk kivételével.
  • Még ha JavaScript is, ezek a webmunkások kontextusában futnak. Ami azt jelenti: nincs DOM, és futtassa a fő szálon kívül.
  • Megérteni az adatbázisok működését.
  • A szolgáltató kódjának külön JavaScript fájlban kell lennie. Példa: service-worker.js

A szolgáltató dolgozók életciklusa

A munkavégzéshez az SW-ket regisztrálni kell az alkalmazáson belül, majd telepíteni kell. Mielőtt ezt megtenné, ellenőriznie kell, hogy az SW-k kompatibilisek-e az ügyfelével.

1) Regisztráció

Ha elérhető, regisztrálja SW fájlját. Ígéretet fog adni, így kezelheti a hibákat. A regisztrációs beállításokban megadhatja az URL-ek körét is.

2) Telepítés

A kiszolgáló dolgozók eseményalapúak. Röviden, visszahívásokat kell csatolnia az eseményekhez, ahogyan azt egy element.addEventListener esetében tenné. Az első használandó esemény a telepítési esemény. Ez egy jó alkalom az összes létfontosságú erőforrás gyorsítótárba helyezésére: Javascript, CSS, HTML, Képek ... Itt csatlakozik a Cache API a párthoz!

Ezután nyissa meg a módszert, vagy hozzon létre egy kívánt névhez kapcsolódó gyorsítótárat. A visszaküldött ígéretet be kell csomagolni az event.waitUntil () fájlba, amely késlelteti a szolgáltató telepítését, amíg az ígéret meg nem oldódik. Ellenkező esetben a telepítési esemény meghiúsul, és a szerviz dolgozó eldobásra kerül.

Kérjük, legyen körültekintő a gyorsítótárral: a felhasználó tárhelye értékes, ezért ne éljen vele vissza. Vigyázzon: a telepítési esemény csak egyszer hívható meg, és annak módosításához frissítenie kell az SW-t.

3) Aktiválás

Ez egy kicsit finom.

A telepítés befejezése után a kiszolgáló még nem aktív: telepített állapotban vagyunk.

Ebben az állapotban várja, hogy átvegye az oldal irányítását. Ezután az életciklus következő szakaszába lép, amely az aktiválási szakasz.

Az aktiválási szakasz hasznos, ha frissít egy SW-t. A leggyakoribb eset az előző telepített SW gyorsítótárának törlése.

Felhívjuk figyelmét, hogy a sikeres telepítés után a frissített munkatárs megvárja, amíg a meglévő dolgozó nulla ügyfelet irányít (az ügyfelek átfedésben vannak egy frissítés során).

A self.skipWaiting () megakadályozza a várakozást, vagyis a szerviz dolgozó aktiválódik, amint befejezte a telepítést. Ennek a módszernek az az előnye, hogy gyorsabban fogadhatja a letöltési eseményeket.

Teljesen mindegy, hogy mikor hívja a skipWaiting () függvényt, mindaddig, amíg a várakozás alatt vagy előtte történik. Elég gyakori, hogy a telepítési eseményben hívják.

Phew! Tartsunk egy kis szünetet, és foglaljuk össze a látottakat:

  • A kiszolgáló munkatársak a JavaScript olyan darabjai, amelyek lehetővé teszik az offline funkciókat, például a gyorsítótárat.
  • Felfedeztük az SW életciklusát: regisztráció, telepítés, aktiválás
  • Megtanultuk, hogyan kell megvalósítani a gyakori felhasználási eseteket, például: erőforrások gyorsítótárba helyezése és a gyorsítótárak törlése a Cache API segítségével.
  • Láttuk, hogy a self.skipWaiting és az self.clients.claim lehetővé teszi számunkra az SW-k gyorsabb aktiválását az események gyorsabb elkapása érdekében.

Rendben haladok jobbra ...

4) Betöltés

A letöltési esemény lehetővé teszi számunkra a hálózati kérések elfogását, a válaszok tárolását vagy testreszabását.

A horog fő előnye, hogy a gyorsítótárazott erőforrásokat visszaküldi ahelyett, hogy kéréshívást kezdeményezne. A kérési hívások kezeléséhez meg kell tekintenie a Fetch API-t.

Nem fedhetjük le egy cikkben a szolgáltatók által kínált összes lehetőséget. Ennek ellenére azt javasoljuk, hogy vizsgálja meg a lehetséges lehetőségeket: Custom 404, Background Sync API offline elemzéshez, ServiceWorker oldali sablonok…. a jövő izgalmasnak tűnik!

Eddig láttuk, hogy mi a szolgáltató, hogyan működik az egész életciklusa alatt, és a leggyakoribb használati esetek a Cache és a Fetch API-val való játékkal. Ez a két API egy teljesen új módszert biztosít az URL címezhető erőforrások kezelésére a böngészőben. Az útmutató befejezéséhez nézze meg, hogyan tárolhatunk más típusú adatokat, például egy felhasználó JSON-ját az adatbázisból.

Tárolja az egyedi adatokat az IndexedDB segítségével

Az adattárolásra vonatkozó általános irányelv az, hogy az URL címezhető erőforrásokat a Cache felületen kell tárolni, az egyéb adatokat pedig az IndexedDB-n. Például a HTML, CSS és JS fájlokat a gyorsítótárban kell tárolni, míg a JSON adatokat az IndexedDB-ben kell tárolni. Vegye figyelembe, hogy ez csak iránymutatás, nem pedig határozott szabály. (forrás)

Röviden, látni fogjuk, amikor nem a Cache API-t, hanem az IndexedDB- t kell használnia . Mindkettő aszinkron és hozzáférhető a szolgáltatást végzőknél, a webmunkásoknál és az ablak felületén. A jó hír az, hogy jól támogatott, még az IE legújabb verzióiban is.

Az IndexedDB egy NoSQL adatbázis. Az IndexedDB adatokat kulcs-érték párokként tárolják az objektumtárolókban, nem pedig táblázatokban. Egyetlen adatbázis tetszőleges számú objektumtárat tartalmazhat. Amikor egy értéket tárol egy objektumtárolóban, egy kulcshoz társul. Ez így néz ki:

Elég klasszikus, igaz? A legfontosabb, amit meg kell érteni, a kulcsút fogalma. Megmondja a böngészőnek, hogy melyik kulccsal lehet adatokat kinyerni az objektumtárból vagy az indexből.

Ebben a példában láthatjuk, hogy a legfontosabb útvonalunk a tulajdonságazonosító, és a 10. sorban van meghatározva. Ezután az összes elemet visszaküldjük az adatbázisból. Ez egy nagyon alapvető használati eset, ezért ha többet szeretne megtudni az IndexedDB működéséről, azt tanácsolom, olvassa el ezt a kiváló cikket.

Következtetés

Az offline web előnyeinek kihasználása nagyszerű a felhasználói élmény szempontjából, és néhány vállalat elkezdett zsákmányolni rajta. Leginkább a szerviz munkatársaira támaszkodik, JavaScript-szkriptekre, amelyek a webhely hátterében futnak.

Láttuk, hogyan kell használni őket a szolgáltató életciklusán keresztül, és mit tehet a Cache és Fetch API használatával. A lehetőségek szinte korlátlanok. ezért legyen kreatív és ne legyen túl mohó az eszköz tárhelyén.

Akár offline is használhatja az adatbázisokat: erre készül az IndexedDB. Ezek az offline képességek minden bizonnyal a web jövőjének részét képezik, ezért jól illeszkedik a Google által létrehozott új típusú webhelyekhez: a Progresszív Webalkalmazásokhoz.

További irodalom:

  • Az offline szakácskönyv: //developers.google.com/web/fundamentals/instant-and-offline/offline-cookbook/
  • PWA és offline: //developers.google.com/web/ilt/pwa/lab-offline-quickstart
  • Lab: Fájlok gyorsítótárazása a Service Workerrel: //developers.google.com/web/ilt/pwa/lab-caching-files-with-service-worker
  • A szolgáltató életciklusa: //developers.google.com/web/fundamentals/primers/service-workers/lifecycle
  • A szolgáltató életciklusának demisztifikálása: //scotch.io/tutorials/demystifying-the-service-worker-lifecycle
  • Gyorsabban aktiválja a Service Workers alkalmazást: //davidwalsh.name/service-worker-claim
  • Élő adatok a szolgáltatónál: //developers.google.com/web/ilt/pwa/live-data-in-the-service-worker
  • IndexedDBAlapfogalmak: //developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API/Basic_Concepts_Behind_IndexedDB
  • Az első lépések az állandó offline tárolással az IndexedDB segítségével: //itnext.io/getting-started-with-persistent-offline-storage-with-indexeddb-1af66727246c