Je hebt dus een progressieve web-app , compleet met een servicemedewerker waarmee deze offline kan werken. Geweldig! U heeft ook een bestaande Google Analytics ingesteld voor uw web-app en u wilt geen analytische inzichten missen die voortkomen uit gebruik dat offline plaatsvindt. Maar als u offline gegevens naar Google Analytics probeert te verzenden, mislukken deze verzoeken en gaan de gegevens verloren.
Het zal u niet verbazen dat de oplossing servicemedewerkers zijn! Concreet voegt het code toe aan uw servicemedewerker om Google Analytics-verzoeken op te slaan (met behulp van IndexedDB ) en deze later opnieuw te proberen wanneer er hopelijk een netwerk beschikbaar is. We deelden code om deze logica af te handelen als onderdeel van de open source Google I/O-webapp , maar realiseerden ons dat dit een nuttig patroon was en dat het kopiëren en plakken van code kwetsbaar kan zijn.
Vandaag kondigen we met genoegen aan dat alles wat u nodig heeft om offline Google Analytics-verzoeken binnen uw servicemedewerker af te handelen, is gebundeld in een npm-pakket : npm install --save-dev sw-offline-google-analytics
Met behulp van sw-offline-google-analytics
Voeg vanuit uw bestaande servicemedewerkercode het volgende toe:
// This code should live inside your service worker JavaScript, ideally
// before any other 'fetch' event handlers are defined:
// First, import the library into the service worker global scope:
importScripts('path/to/offline-google-analytics-import.js');
// Then, call goog.offlineGoogleAnalytics.initialize():
// See https://github.com/GoogleChrome/workbox/tree/main/packages/workbox-google-analytics
goog.offlineGoogleAnalytics.initialize();
// At this point, implement any other service worker caching strategies
// appropriate for your web app.
Dat is alles wat er is!
Wat gebeurt er onder de motorkap?
sw-offline-google-analytics stelt een nieuwe fetch in uw servicemedewerker in, die reageert op verzoeken aan het Google Analytics-domein . (De bibliotheek negeert niet-Google Analytics-verzoeken, waardoor de andere fetch van uw servicemedewerker de kans krijgen om geschikte strategieën voor die bronnen te implementeren.) Er wordt eerst geprobeerd het verzoek aan het netwerk uit te voeren. Als de gebruiker online is, verloopt dat normaal.
Als het netwerkverzoek mislukt , slaat de bibliotheek automatisch informatie over het verzoek op in IndexedDB , samen met een tijdstempel die aangeeft wanneer het verzoek voor het eerst is gedaan. Elke keer dat uw servicemedewerker opstart , controleert de bibliotheek of er verzoeken in de wachtrij staan en wordt geprobeerd deze opnieuw te verzenden , samen met enkele aanvullende Google Analytics-parameters:
- Een
qtparameter , ingesteld op de hoeveelheid tijd die is verstreken sinds de aanvraag voor het eerst werd geprobeerd, om ervoor te zorgen dat de oorspronkelijke tijd correct wordt toegewezen. - Eventuele aanvullende parameters en waarden die zijn opgegeven in de eigenschap
parameterOverridesvan het configuratieobject, worden doorgegeven aangoog.offlineGoogleAnalytics.initialize(). U kunt bijvoorbeeld een aangepaste dimensie opnemen om onderscheid te maken tussen verzoeken die opnieuw zijn verzonden door de servicemedewerker en verzoeken die onmiddellijk zijn verzonden.
Als het opnieuw verzenden van het verzoek lukt, dan is dat prima! Het verzoek wordt verwijderd uit IndexedDB. Als de nieuwe poging mislukt en de eerste aanvraag minder dan 24 uur geleden is gedaan, wordt deze in IndexedDB bewaard en opnieuw geprobeerd de volgende keer dat de servicemedewerker start. Houd er rekening mee dat Google Analytics-hits ouder dan vier uur niet gegarandeerd worden verwerkt, maar het opnieuw versturen van wat oudere hits "voor het geval dat" zou geen kwaad kunnen.
sw-offline-google-analytics implementeert ook een 'netwerk eerst, terugvallend op cache'-strategie voor de daadwerkelijke analytics.js JavaScript-code die nodig is om Google Analytics op te starten.
Er komt nog meer!
sw-offline-google-analytics maakt deel uit van het grotere sw-helpers -project , een verzameling bibliotheken die bedoeld zijn om drop-in-verbeteringen te bieden aan bestaande implementaties van servicemedewerkers.
Ook onderdeel van dat project is sw-appcache-behavior , een bibliotheek die cachingstrategieën implementeert die zijn gedefinieerd in een bestaand AppCache-manifest in een servicemedewerker. Het is bedoeld om u te helpen migreren van AppCache naar servicewerknemers terwijl u, althans in eerste instantie, een consistente cachingstrategie handhaaft.
Als u andere bibliotheekideeën heeft, horen wij dat graag. Dien dus een verzoek in in de issuetracker !