💡Cet article fait parti d'une série d'articles autour des services workers, les autres chapitres sont disponibles ci-dessous.

Les services workers — 1ère partie : Introduction, fonctionnement et installation
Comprendre et installer un service worker en 3 minutes : Qu’est-ce c’est ? Comment ça fonctionne et à quoi cela va me servir ?

À un moment ou un autre, il faudra mettre à jour le code du service worker (SW). Une séquence de 2 étapes va alors débuter.

Ce schéma résume l'enchainement que nous allons étudier.
(désolé pour les utilisateurs de 🦊Firefox, il semblerait que l'animation bug…)

I — La détection de la mise à jour

De manière générale, il y a trois raisons qui peuvent pousser un SW à se mettre à jour (ou du moins essayer).

La première intervient à chaque fois que l'on arrive sur l'application web (au chargement du script). Dans le cadre d'une application JS type react ou vue, cet évènement ne surviendra qu'au rechargement de la page (initialisation de react). Pour un site web « classique » sans librairie de router JS, cela pourra se faire à chaque changement de page et donc à chaque clic sur un lien interne.

La seconde: lorsqu'un événement fonctionnel push et/ou sync est déclenché. À moins qu'il n'y ait eu une vérification de mise à jour au cours des 24 dernières heures.

La troisième: c'est la méthode manuelle, si on pense que l'utilisateur va rester sur l'application souvent sans rafraîchir, on peut définir un interval de tentative de mise à jour toutes les heures par exemple :

navigator.serviceWorker.register('/service-worker.js').then(reg => {
  // Toutes les heures
  setInterval(() => reg.update(), 3600000)
});

Lorsque une de ces actions se produit : le SW va être téléchargé en arrière plan, le navigateur va ensuite comparer le service worker actif et celui récupéré depuis le serveur. Au moindre octet de différence  le service worker est considéré comme étant mis à jour. Ce comportement est étendue pour inclure également les scripts/modules importés.

À ce moment là, le nouveau SW s'installe et l'évènement install est déclenché.

Cependant, si jamais le nouveau SW:

  • Récupère une erreur status code HTTP différent de OK (Hors plage 2XX des codes retours HTTP).
  • Obtient une erreur de parsing du code ou un throw de n'importe quelle erreur dans le code.
  • Ou obtient un reject de la part d'une promesse (« promise »).

tout cela au moment de l'installation, alors le nouveau SW est jeté et l'actuel reste en place. Ce comportement permet de garder un état fonctionnel de l'application.

II — La phase d'attente et de remplacement

Lorsque l'installation effective,  à ce moment là, l'ancien SW contrôle toujours la page et comme un seul SW peut être actif à la fois, le nouveau rentre dans l'état waiting.

Une fois que tous les onglets du navigateur (clients) ayant le site ouvert seront fermés : le SW 1 sera détruit et le nouveau prendra la main.

Attention: dans le cas d'une PWA il faudra bien penser à kill l'application à la main, nous verrons des astuces pour forcer la mise à jour un peu plus tard.

Il est possible de dire au nouveau service worker de s'activer le plus rapidement possible dès qu'il le peut, dans le ce il faut utiliser la méthode skipWaiting. Cette manipulation sera détaillée dans le prochain article « Mise à jour avancées ». Nous y verrons également comment inviter l'utilisateur à procéder à la mise à jour en lui présentant une invitation à l'écran.

Une fois le nouveau worker activé, l'évènement activate est déclenché et le nouveau worker prends la main

C'est à ce moment là (et uniquement à partir de celui-là) que l'on peut commencer à modifier le cache dans le cadre de la nouvelle version du SW.

En effet, l'ancien worker contrôle la page encore à ce moment, si l'on avait fait cela à l'évènement install, nous aurions risqué d'avoir des effets de bords avec l'ancien SW, en modifiant des fichiers de cache potentiellement utilisés actuellement pour le bon fonctionnement de l'application.

On peut cependant créer de nouvelles choses dans un nouveau cache (en ajoutant un suffixe avec version par exemple) lors de l'évènement install, afin de pre-fetcher des contenus pour plus tard par exemple.


On sait désormais de quelle manière se met à jour un SW, dans la prochaine partie nous irons plus loin sur la communication entre la page et le script du SW, notamment en montrant comment communiquer entre les deux pour échanger des informations.