Gdy wysyłasz żądania do serwera WWW, może wystąpić błąd. Przyczyną może być utrata połączenia lub awaria serwera zdalnego.
W tej dokumentacji skupiliśmy się głównie na obsłudze żądań GET
w skrypcie service worker, jednak pomocne mogą okazać się również inne metody, takie jak POST
, PUT
lub DELETE
. Te metody są często używane do komunikowania się z interfejsami API backendu w celu dostarczania danych dla aplikacji internetowej. Jeśli te żądania zakończą się niepowodzeniem z powodu braku skryptu service worker, użytkownik musi je ponawiać ręcznie, gdy odzyskasz połączenie z internetem.
Jeśli dotyczy to Twojej aplikacji, a skryptor service worker należy do grupy, najlepiej jest ponowić próbę wysłania nieudanych żądań, gdy użytkownik znów będzie online. Rozwiązaniem tego problemu jest BackgroundSync API. Gdy skrypt service worker wykryje nieudane żądanie sieciowe, może się zarejestrować, aby otrzymać zdarzenie sync
, gdy przeglądarka wykryje, że połączenie zostało przywrócone. Zdarzenie sync
może być zrealizowane nawet wtedy, gdy użytkownik opuścił stronę, na której je zarejestrowało. Dzięki temu jest to bardziej skuteczne niż inne metody ponawiania nieudanych żądań.
Workbox wykorzystuje moduł workbox-background-sync
, dzięki czemu interfejs BackgroundSync API jest łatwiejszy w użyciu z innymi modułami Workbox. Stosuje także strategię awaryjną dla przeglądarek, które nie obsługują jeszcze funkcji BackgroundSync.
Podstawowe użycie
Interfejs BackgroundSyncPlugin
jest eksportowany z modułu workbox-background-sync
i można go używać do umieszczania w kolejce nieudanych żądań oraz ponowienia ich po uruchomieniu przyszłych zdarzeń sync
:
import {BackgroundSyncPlugin} from 'workbox-background-sync';
import {registerRoute} from 'workbox-routing';
import {NetworkOnly} from 'workbox-strategies';
const bgSyncPlugin = new BackgroundSyncPlugin('myQueueName', {
maxRetentionTime: 24 * 60 // Retry for max of 24 Hours (specified in minutes)
});
registerRoute(
/\/api\/.*\/*.json/,
new NetworkOnly({
plugins: [bgSyncPlugin]
}),
// An optional third parameter specifies the request method
'POST'
);
Metoda BackgroundSyncPlugin
jest tu stosowana do trasy pasującej do żądań POST do trasy interfejsu API, która pobiera dane JSON. Jeśli użytkownik jest offline, BackgroundSyncPlugin
ponowi próbę wysłania żądania, gdy znów będzie online, ale tylko na jeden dzień.
Zaawansowane użycie
workbox-background-sync
udostępnia również klasę Queue
, do której możesz tworzyć wystąpienia i dodawać nieudane żądania. Tak jak w przypadku funkcji BackgroundSyncPlugin
, nieudane żądania są przechowywane w IndexedDB i są podejmowane, gdy przeglądarka uzna, że połączenie zostało przywrócone.
Tworzenie kolejki
Aby utworzyć kolejkę, utwórz instancję obiektu Queue
z ciągiem znaków reprezentującym nazwę kolejki:
import {Queue} from 'workbox-background-sync';
const queue = new Queue('myQueueName');
Nazwa kolejki jest częścią nazwy tagu tworzonej przez metodę register()
dostarczaną przez globalny SyncManager
. Jest to również nazwa używana na potrzeby magazynu obiektów udostępnianej przez bazę danych IndexedDB.
Dodaję żądania do kolejki
Po utworzeniu instancji Queue
możesz dodać do niej nieudane żądania przy użyciu metody pushRequest()
:
import {Queue} from 'workbox-background-sync';
const queue = new Queue('myQueueName');
self.addEventListener('fetch', (event) => {
// Add in your own criteria here to return early if this
// isn't a request that should use background sync.
if (event.request.method !== 'POST') {
return;
}
const bgSyncLogic = async () => {
try {
const response = await fetch(event.request.clone());
return response;
} catch (error) {
await queue.pushRequest({request: event.request});
return error;
}
};
event.respondWith(bgSyncLogic());
});
Po dodaniu do kolejki żądania są automatycznie ponawiane, gdy skrypt service worker odbiera zdarzenie sync
, ponieważ przeglądarka uznaje, że sieć jest ponownie dostępna. Przeglądarki, które nie obsługują interfejsu BackgroundSync API, będą ponawiać żądanie przy każdym uruchomieniu mechanizmu Service Worker. Jest to mniej efektywny sposób ponawiania nieudanych żądań, ale różnego rodzaju.
Testowanie urządzenia workbox-background-sync
Testowanie działania synchronizacji w tle może być trudne, ale można to zrobić w Narzędziach deweloperskich w Chrome. Obecnie najlepsza metoda jest podobna do tej:
- Otwórz stronę rejestrującą skrypt service worker.
- Wyłącz połączenie sieciowe komputera lub wyłącz serwer WWW. Nie używaj przełącznika trybu offline w Narzędziach deweloperskich w Chrome. Pole wyboru offline wpływa tylko na żądania ze strony, ale żądania mechanizmów Service Worker nadal będą realizowane.
- Wysyłaj żądania sieciowe, które powinny znaleźć się w kolejce za pomocą funkcji
workbox-background-sync
. Żądania oczekujące w kolejce możesz sprawdzić wChrome DevTools > Application > IndexedDB > workbox-background-sync > requests
. - Przywróć połączenie z siecią lub włącz z powrotem serwer WWW.
- Wymuś wczesne zdarzenie
sync
, przechodząc doChrome DevTools > Application > Service Workers
. Wpisz nazwę taguworkbox-background-sync:<your queue name>
, gdzie<your queue name>
to nazwa ustawionej kolejki. - Kliknij przycisk „Synchronizuj”. przycisk.
- Powinny być teraz widoczne wcześniejsze nieudane żądania sieci ponowione i przejściowe. W związku z tym magazyn IndexedDB powinien być pusty, ponieważ żądania zostały ponownie odtworzone.
Podsumowanie
Użycie workbox-background-sync
do ponawiania nieudanych żądań sieciowych może być świetnym sposobem na zwiększenie wygody użytkowników i niezawodności aplikacji. Może na przykład umożliwić użytkownikom ponowne przesyłanie nieudanych żądań do interfejsu API, tak aby nie utracili oni danych wysłanych do Twojego interfejsu API. Za pomocą tej funkcji możesz też uzupełnić luki we własnych danych, np. w statystykach. Moduł workbox-google-analytics
wykorzystuje wewnętrzne dane workbox-background-sync
do ponawiania nieudanych żądań wysyłania danych do Google Analytics.
Niezależnie od Twojego zastosowania, workbox-background-sync
upraszcza ten rodzaj zadań, ulepszając środowisko programistyczne i dając Ci więcej możliwości poprawy funkcjonalności i funkcjonalności aplikacji internetowej.