Le Service Worker dans une PWA est la pièce maîtresse du mécanisme offline
Service Worker, les grans principes
Un Service Worker agit comme un proxy pour votre site :
Il prendra le contrôle de tout ce qui sort de votre page web. De plus, il sera amené à ‘réveiller’ votre site grâce à un mécanisme d’événements.
Cycle de vie
Un seul Service Worker peut être actif en même temps sur une page. De même il n’y a qu’une seule instance d’un Service Worker partagée entre toutes les instances de pages web ouvertes dans un même navigateur.
Afin d’avoir une cohérence entre toutes les pages, un Service Worker est lié a un cycle de vie. Le fonctionnement par défaut est le suivant : une nouvelle version d’un Service Worker est active que si toutes les instances de la page ont été fermées.
Basé sur des événements
Chaque étape du cycle de vie se produit dans le Service Worker sous forme d’événements Javascript.
Ainsi lors de l’installation d’un Service Worker, l’événement install est levé. Lorsqu’un Service Worker est actif, l’événement activate est levé. L’état ‘idle’ ne lève aucun événement. En revanche, tous les autres événements qui peuvent survenir seront levés par un événement javascript : fetch, push, message, sync, notificationclick, periodicsync.
Cependant, tous les événements ne sont pas encore supportés par tous les navigateurs.
Stratégies de caches
Un Service Worker nous permettra de mettre en place plusieurs stratégies de cache à utiliser dans notre application. De cette manière, nous contrôler la ‘fraicheur’ des données à afficher.
Voici quelques exemples de stratégies qui peuvent être appliquées avec un Service Worker : ‘Cache-Only’, ‘Network-Only’, ‘Cache-First’, ‘Network-First’, ‘Cache-Then-Network’, ‘Stale-While-Revalidate’, ‘Generic-Fallback’