Hoe u uw app offline kunt laten werken met de kracht van JavaScript

In de wereld van vandaag heeft connectiviteit ons mobieler gemaakt dan ooit, waardoor we (paradoxaal genoeg) soms offline zijn: als we in de vliegtuigmodus zijn, een slechte verbinding hebben, geen gegevens meer hebben, in de metro zitten ... enzovoort.

Een tweede effect van deze mobiliteit is het traag laden van zware websites: Amazon ontdekte dat slechts 100 milliseconden extra laadtijd hen 1% van de omzet kostte.

In deze situaties willen we offline toegang tot onze inhoud. Daarom bestaan ​​er tools als Instapaper en Pocket. Met Spotify en Netflix kunt u ook media downloaden voor offline gebruik.

We kunnen gemakkelijk zien dat er vraag is naar deze functie en hoe uw bedrijf hiervan kan profiteren.

Het is tijd dat het web offline gaat.

Gelukkig hoeven we geen native apps meer te bouwen om dit doel te bereiken. We kunnen een offline website maken met de kracht van JavaScript dankzij de nieuwe servicemedewerkers en Cache API- functies.

Wat is een servicemedewerker (SW)?

Servicemedewerkers zijn JavaScript-code die op de achtergrond van uw website wordt uitgevoerd, zelfs wanneer de pagina is gesloten. Voor offline gebruik is een van hun doelen om netwerkverzoeken of afbeeldingen op te slaan in de browsercache.

Het bureau BETC heeft voor het Franse telecombedrijf Bouygues een demo website gemaakt met de naam whentheinternetisdown.com. Het werkt alleen offline en voelt magisch aan. Ga het proberen :)

Het is de caching die de magie van de site maakt: je kunt binnen 3 weken, 1 maand, 1 jaar terugkomen, nog steeds zonder verbinding, en toegang krijgen tot alle inhoud. - Maxime Huygue, hoofd van BETC Digital Studio

Oké, dit is cool, vertel me dan hoe ik het moet doen.

Oké, laten we beginnen met enkele voorwaarden:

  • Om SW's te kunnen gebruiken, moet u https op uw website inschakelen.
  • U moet een goed begrip hebben van hoe JavaScript-beloften werken.
  • SWs werkt in alle moderne browsers behalve onze vriend IE.
  • Zelfs als het JavaScript is, worden ze uitgevoerd in de context van webwerkers. Wat betekent: geen DOM, en buiten de rode draad lopen.
  • Begrijp hoe databases werken.
  • De code van uw servicemedewerker moet in een apart JavaScript-bestand staan. Voorbeeld: service-worker.js

Levenscyclus van servicemedewerkers

Om te kunnen werken, moeten SW's in uw applicatie worden geregistreerd en vervolgens worden geïnstalleerd. U moet controleren of SW's compatibel zijn met uw client voordat u dit doet.

1) Registratie

Registreer uw SW-bestand, indien beschikbaar. Het zal een belofte retourneren, zodat u met fouten kunt omgaan. U kunt ook een bereik van URL's specificeren in de registratie-opties.

2) Installatie

Servicemedewerkers zijn gebaseerd op gebeurtenissen. In het kort: u moet callbacks aan gebeurtenissen koppelen, zoals u zou doen met een element.addEventListener. De eerste gebeurtenis die u moet gebruiken, is de installatiegebeurtenis. Dit is een goed moment om al uw vitale bronnen zoals Javascript, CSS, HTML, afbeeldingen… in het cachegeheugen op te slaan. Hier komt de Cache API bij!

Open vervolgens de methode of maak een cache aan die is gekoppeld aan een gewenste naam. De geretourneerde belofte moet worden verpakt in event.waitUntil (), waardoor de installatie van de servicemedewerker wordt vertraagd totdat de belofte is opgelost. Anders mislukt de installatiegebeurtenis en wordt de servicemedewerker genegeerd.

Wees voorzichtig met caching: de opslag van uw gebruiker is kostbaar, dus maak er geen misbruik van. Wees ook voorzichtig: de installatiegebeurtenis kan maar één keer worden aangeroepen en u moet uw SW bijwerken om deze te wijzigen.

3) Activering

Deze is een beetje subtiel.

Als de installatie is voltooid, is de servicemedewerker nog niet actief: we bevinden ons in de geïnstalleerde toestand.

In deze toestand wacht het om de controle over de pagina over te nemen. Vervolgens gaat het over naar de volgende fase in de levenscyclus, de activeringsfase.

De activeringsfase is handig wanneer u een software update. Het meest voorkomende geval is het wissen van de cache van de vorige geïnstalleerde software.

Houd er rekening mee dat, eenmaal geïnstalleerd, de bijgewerkte werker wacht totdat de bestaande werker nul clients bestuurt (clients overlappen elkaar tijdens het vernieuwen).

self.skipWaiting () voorkomt het wachten, wat betekent dat de servicemedewerker wordt geactiveerd zodra deze klaar is met installeren. Het voordeel van deze methode is dat u ophaalgebeurtenissen sneller kunt ontvangen.

Het maakt niet echt uit wanneer je skipWaiting () aanroept, zolang het maar tijdens of voor het wachten is. Het is vrij gebruikelijk om het te noemen tijdens de installatiegebeurtenis.

Opluchting! Laten we een pauze nemen en samenvatten wat we hebben gezien:

  • Servicemedewerkers zijn stukjes JavaScript die offline functies zoals caching mogelijk maken.
  • We hebben de SW Lifecycle onderzocht: registratie, installatie, activering
  • We hebben geleerd hoe we veelvoorkomende toepassingen kunnen implementeren, zoals: caching van bronnen en het wissen van caches met de Cache API.
  • We hebben gezien dat self.skipWaiting en self.clients.claim ons in staat stellen om SW's sneller te activeren om gebeurtenissen sneller op te vangen.

Oké, gewoon doorgaan ...

4) Ophalen

Met de fetch-gebeurtenis kunnen we netwerkverzoeken onderscheppen en reacties opslaan of aanpassen.

Het belangrijkste voordeel van deze hook is om de bronnen in de cache te retourneren in plaats van een verzoekoproep te doen. Bekijk de Fetch API voor het afhandelen van uw verzoekoproepen.

We kunnen niet alle mogelijkheden van servicemedewerkers in één artikel behandelen. Toch moedig ik je aan om te kijken wat er mogelijk is: Custom 404, Background Sync API voor offline analyse, ServiceWorker-side sjablonen…. de toekomst ziet er spannend uit!

Tot nu toe hebben we gezien wat een servicemedewerker is, hoe het werkt tijdens zijn levenscyclus en de meest voorkomende gebruiksscenario's door te spelen met Cache en Fetch API. Deze twee API's geven ons een geheel nieuwe manier om URL-adresseerbare bronnen in de browser te beheren . Om deze handleiding compleet te maken, laten we eens kijken hoe we andere soorten gegevens kunnen opslaan, bijvoorbeeld de JSON van een gebruiker uit uw database.

Sla aangepaste gegevens op met IndexedDB

Een algemene richtlijn voor gegevensopslag is dat URL-adresseerbare bronnen moeten worden opgeslagen met de Cache-interface en dat andere gegevens moeten worden opgeslagen met IndexedDB. HTML-, CSS- en JS-bestanden moeten bijvoorbeeld in de cache worden opgeslagen, terwijl JSON-gegevens moeten worden opgeslagen in IndexedDB. Merk op dat dit slechts een richtlijn is, geen vaste regel. (bron)

Kortom, we zullen zien wanneer u in plaats daarvan geen Cache API maar IndexedDB moet gebruiken. Beide zijn asynchroon en toegankelijk voor servicemedewerkers, webwerkers en de vensterinterface. Het goede nieuws is dat het goed wordt ondersteund, zelfs in recente versies van IE.

IndexedDB is een NoSQL-database. IndexedDB-gegevens worden opgeslagen als sleutel-waardeparen in objectarchieven in plaats van tabellen. Een enkele database kan een willekeurig aantal objectarchieven bevatten. Telkens wanneer een waarde wordt opgeslagen in een objectarchief, wordt deze geassocieerd met een sleutel. Het ziet er zo uit:

Best klassiek, toch? Het belangrijkste dat u moet begrijpen, is het concept van het sleutelpad. Het vertelt de browser welke sleutel moet worden gebruikt om gegevens uit het objectarchief of de index te extraheren.

In dit voorbeeld kunnen we zien dat ons sleutelpad de eigenschap-id is, en het wordt gedefinieerd in regel 10. Vervolgens retourneren we alle items uit de database. Dit is een heel eenvoudige use-case, dus als je meer wilt weten over hoe IndexedDB werkt, raad ik je aan dit uitstekende artikel te lezen.

Conclusie

Profiteren van het offline web is geweldig voor de gebruikerservaring, en sommige bedrijven beginnen er buit mee te maken. Het is meestal afhankelijk van servicemedewerkers, JavaScript-scripts die op de achtergrond van uw website worden uitgevoerd.

We hebben gezien hoe u ze kunt gebruiken tijdens de levenscyclus van servicemedewerkers en wat u kunt doen met behulp van de Cache en Fetch API. De mogelijkheden zijn vrijwel onbegrensd. dus wees creatief en niet te hebberig over de opslag van het apparaat.

U kunt zelfs databases offline gebruiken: daar is IndexedDB voor gemaakt. Deze offline mogelijkheden maken zeker deel uit van de toekomst van internet, dus het speelt goed met het nieuwe type websites dat Google maakt: Progressive Web Apps.

Verder lezen:

  • Het offline kookboek: //developers.google.com/web/fundamentals/instant-and-offline/offline-cookbook/
  • PWA en offline: //developers.google.com/web/ilt/pwa/lab-offline-quickstart
  • Lab: bestanden cachen met servicemedewerker: //developers.google.com/web/ilt/pwa/lab-caching-files-with-service-worker
  • De levenscyclus van servicemedewerkers: //developers.google.com/web/fundamentals/primers/service-workers/lifecycle
  • Demystificatie van de levenscyclus van servicemedewerkers: //scotch.io/tutorials/demystifying-the-service-worker-lifecycle
  • Activeer servicemedewerkers sneller: //davidwalsh.name/service-worker-claim
  • Live gegevens in de servicemedewerker: //developers.google.com/web/ilt/pwa/live-data-in-the-service-worker
  • IndexedDBBasisconcepten: //developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API/Basic_Concepts_Behind_IndexedDB
  • Aan de slag met permanente offline opslag met IndexedDB: //itnext.io/getting-started-with-persistent-offline-storage-with-indexeddb-1af66727246c