casella di lavoro-sincronizzazione-in background

Quando invii i dati a un server web, a volte le richieste non vanno a buon fine. it potrebbe essere dovuto alla perdita di connettività dell'utente o al fatto che il server non è attivo; in entrambi i casi spesso vorrai provare a inviare le richieste di nuovo in seguito.

La nuova API BackgroundSync rappresentano la soluzione ideale a questo problema. Quando un service worker rileva che un richiesta di rete non riuscita, può registrarsi per ricevere un evento sync, che viene consegnato quando il browser ritiene che la connettività sia stata restituita. Tieni presente che l'evento di sincronizzazione può essere inviato anche se l'utente ha abbandonato la applicazione, il che la rende molto più efficace rispetto al metodo tradizionale riprova a eseguire le richieste non riuscite.

La sincronizzazione in background Workbox è progettata per facilitare l'utilizzo l'API BackgroundSync e ne integra l'utilizzo con altri moduli Workbox. it implementano anche una strategia di riserva per i browser che non implementano ancora Sincronizzazione in background.

La riproduzione automatica non è riuscita per i browser che supportano l'API BackgroundSync richieste per tuo conto presso gestito dal browser, probabilmente con il backoff esponenziale tra tentativi di riproduzione. Nei browser l'API BackgroundSync in modo nativo, Workbox Background Sync, e un tentativo automatico di ripetizione a ogni avvio del service worker.

Utilizzo di base

Il modo più semplice per utilizzare la sincronizzazione in background è usare la Plugin che Mettere automaticamente in coda le richieste non riuscite e riprovare quando sync in futuro vengono attivati.

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],
  }),
  'POST'
);

BackgroundSyncPlugin si aggancia a callback per il plug-in fetchDidFail e fetchDidFail viene richiamato solo se è presente un'eccezione, molto probabilmente dovuta a un errore di rete. Ciò significa che le richieste non verranno ritentate se è presente un risposta ricevuta con un Stato di errore 4xx o 5xx. Se vuoi riprovare tutte le richieste che generano, ad esempio, lo stato 5xx, puoi farlo aggiunta di un plug-in fetchDidSucceed alla tua strategia:

const statusPlugin = {
  fetchDidSucceed: ({response}) => {
    if (response.status >= 500) {
      // Throwing anything here will trigger fetchDidFail.
      throw new Error('Server error.');
    }
    // If it's not 5xx, use the response as-is.
    return response;
  },
};

// Add statusPlugin to the plugins array in your strategy.

Utilizzo avanzato

Workbox Background Sync fornisce anche una classe Queue, che puoi creare un'istanza e aggiungere le richieste non riuscite. Le richieste non riuscite vengono memorizzate in IndexedDB e vengono tentati di nuovo quando il browser ritiene che la connettività sia stata ripristinata (ad esempio quando riceve l'evento di sincronizzazione).

Creazione di una coda in corso...

Per creare una coda di sincronizzazione in background della casella di lavoro, devi crearla con un nome coda (che deve essere univoco per il tuo origin):

import {Queue} from 'workbox-background-sync';

const queue = new Queue('myQueueName');

Il nome della coda viene utilizzato come parte del nome del tag che register()-ed dal mondo SyncManager. È utilizzata anche come Nome dell'archivio oggetti per del database IndexedDB.

Aggiunta di una richiesta alla coda

Dopo aver creato l'istanza Queue, puoi aggiungervi le richieste non riuscite. Puoi aggiungere una richiesta non riuscita richiamando il metodo .pushRequest(). Ad esempio: il seguente codice rileva le richieste non riuscite e le aggiunge alla coda:

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());
});

Una volta aggiunta alla coda, la richiesta viene ritentata automaticamente quando il service worker riceve l'evento sync (che si verifica quando il browser ritiene che la connettività sia stata ripristinata). I browser che non supportano L'API BackgroundSync proverà nuovamente a inserire la coda ogni volta che il service worker è tutto pronto per iniziare. Ciò richiede che la pagina che controlla il service worker quindi non sarà altrettanto efficace.

Test della sincronizzazione in background casella di lavoro

Purtroppo testare BackgroundSync è alquanto inintuitivo e difficile per diversi motivi.

L'approccio migliore per testare l'implementazione è seguire questi passaggi:

1. Carica una pagina e registra il tuo service worker.
2. Disattiva la rete del computer o disattiva il server web.
   • NON UTILIZZARE CHROME DEVTOOLS OFFLINE. La casella di controllo offline in DevTools influisce solo sulle richieste dalla pagina. Richieste dei service worker continuerà ad andare avanti.
3. Effettua richieste di rete che devono essere messe in coda con Workbox Background Sync.
   • Puoi controllare che le richieste siano state messe in coda controllando Chrome DevTools > Application > IndexedDB > workbox-background-sync > requests
4. Ora attiva la rete o il server web.

5. Forza un evento sync in anticipo visitando Chrome DevTools > Application > Service Workers, inserendo il nome tag workbox-background-sync:<your queue name> dove <your queue name> dovrebbe essere il nome della coda impostata, quindi fai clic sul pulsante "Sincronizza" .

   

6. Dovresti vedere che le richieste di rete vanno a buon fine per le richieste non riuscite. i dati IndexedDB ora dovrebbero essere vuoti poiché le richieste sono state riprodotta correttamente.