Masz progresywną aplikację internetową wraz z skryptą service worker, która pozwala na pracę w trybie offline. Świetnie! Twoja aplikacja internetowa jest już skonfigurowana w Google Analytics, więc nie chcesz przegapić żadnych statystyk związanych z użytkowaniem aplikacji offline. Próba wysłania danych do Google Analytics w trybie offline nie powiedzie się, a dane zostaną utracone.
Rozwiązaniem są pracownicy service worker. Konkretnie dodaje to kod do skryptu service worker, który pozwala przechowywać żądania Google Analytics (za pomocą IndexedDB) i próbuje je ponownie później, gdy sieć (jeśli będzie dostępna) będzie dostępna. Udostępniliśmy kod, aby obsługiwać tę logikę w ramach open source aplikacji internetowej Google I/O. Okazało się jednak, że jest to przydatny wzorzec i można go było skopiować i wkleić.
Z przyjemnością informujemy, że wszystko, czego potrzebujesz do obsługi żądań Google Analytics offline w skrypcie service worker, zostało zebrane w pakiecie npm: npm install --save-dev sw-offline-google-analytics
Korzystanie z sw-offline-google-analytics
W istniejącym kodzie skryptu service worker dodaj:
// 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.
To już wszystko.
Co się dzieje pod maską?
sw-offline-google-analytics konfiguruje w skrypcie service worker nowy moduł obsługi zdarzeń fetch, który odpowiada na żądania wysyłane do domeny Google Analytics. Biblioteka ignoruje żądania spoza Google Analytics, dzięki czemu pozostałe moduły obsługi zdarzeń fetch skryptu service worker mogą zaimplementować odpowiednie strategie w przypadku tych zasobów. Najpierw zostanie podjęta próba zrealizowania żądania w sieci. Jeśli użytkownik jest online, proces będzie przebiegać w zwykły sposób.
Jeśli żądanie sieciowe nie powiedzie się, biblioteka automatycznie zapisze informacje o żądaniu do IndexedDB wraz z sygnaturą czasową wskazującą, kiedy żądanie zostało wysłane po raz pierwszy. Przy każdym uruchomieniu skryptu service worker biblioteka sprawdza, czy są jakieś żądania w kolejce i próbuje je wysłać ponownie, wraz z kilkoma dodatkowymi parametrami Google Analytics:
- Parametr
qtustawiony na czas, który upłynął od pierwszej próby wysłania żądania. Pozwala to upewnić się, że pierwotna godzina została poprawnie przypisana. - Dodatkowe parametry i wartości podane we właściwości
parameterOverridesobiektu konfiguracji przekazywanego dogoog.offlineGoogleAnalytics.initialize(). Możesz na przykład uwzględnić wymiar niestandardowy, aby odróżnić żądania wysłane ponownie przez skrypt service worker od tych, które zostały wysłane natychmiast.
Jeśli prośba zostanie wysłana ponownie, to świetnie. Żądanie zostało usunięte z IndexedDB. Jeśli ponawianie próby nie powiedzie się, a pierwsze żądanie zostało wysłane mniej niż 24 godziny temu, zostanie zachowane w IndexedDB i zostanie ono ponowione przy następnym uruchomieniu skryptu service worker. Pamiętaj, że nie gwarantujemy przetworzenia działań Google Analytics starszych niż cztery godziny, ale na wszelki wypadek ponowne wysłanie starszych działań nie powinno zaszkodzić.
sw-offline-google-analytics implements strategię „najpierw sieci, cofając się do pamięci podręcznej” dla rzeczywistego analytics.jskodu JavaScript niezbędnego do wczytywania Google Analytics.
To jeszcze nie wszystko!
sw-offline-google-analytics jest częścią większego projektu sw-helpers, który jest zbiorem bibliotek przeznaczonych do udostępniania rozszerzalnych rozszerzeń do istniejących implementacji skryptu service worker.
Częścią tego projektu jest też sw-appcache-behavior – biblioteka, która implementuje strategie buforowania zdefiniowane w istniejącym pliku manifestu AppCache w skrypcie service worker. Ma pomóc w migracji z AppCache do mechanizmów Service Worker, a jednocześnie zachować spójną strategię buforowania (przynajmniej na początku).
Jeśli masz inne pomysły na bibliotekę, chętnie poznamy Twoją opinię. Prośbę możesz przesłać za pomocą narzędzia do śledzenia problemów.