Update

Vous avez publié votre PWA: certains utilisateurs l'utilisent depuis leur navigateur, d'autres l'installent sur leurs appareils. Lorsque vous mettez à jour l'application, il est important d'appliquer les bonnes pratiques pour éviter les pièges.

Vous pouvez mettre à jour:

  • Données des applications.
  • Éléments déjà mis en cache sur les appareils.
  • Fichier du service worker ou ses dépendances.
  • Métadonnées du fichier manifeste.

Examinons les bonnes pratiques pour chacun de ces éléments.

Mettre à jour des données

Pour mettre à jour des données, telles que celles qui sont stockées dans IndexedDB, vous pouvez utiliser des outils tels que Fetch, WebRTC ou l'API WebSockets. Si votre application est compatible avec des fonctionnalités hors connexion, n'oubliez pas de mettre également à jour les données compatibles avec ces fonctionnalités.

Dans les navigateurs compatibles, il existe des options pour synchroniser les données, non seulement lorsque l'utilisateur ouvre la PWA, mais aussi en arrière-plan. Ces options sont les suivantes:

  • Synchronisation en arrière-plan: les requêtes ayant échoué sont enregistrées et relancées à partir du service worker.
  • Synchronisation Web périodique en arrière-plan: synchronise les données périodiquement en arrière-plan, à des heures spécifiques, ce qui permet à l'application de fournir des données à jour même si l'utilisateur ne l'a pas encore ouverte.
  • Récupération en arrière-plan: télécharge des fichiers volumineux, même lorsque la PWA est fermée.
  • Web push: envoie un message du serveur qui active le service worker et avertit l'utilisateur. C'est ce qu'on appelle communément une "notification push". Cette API nécessite l'autorisation de l'utilisateur.

Toutes ces API sont exécutées à partir du contexte du service worker. Ils ne sont actuellement disponibles que dans les navigateurs basés sur Chromium, sur Android et sur les systèmes d'exploitation pour ordinateur. Lorsque vous utilisez l'une de ces API, vous pouvez exécuter du code dans le thread de service worker, par exemple pour télécharger des données depuis votre serveur et mettre à jour vos données IndexedDB.

Mise à jour des éléments...

La mise à jour des éléments inclut toutes les modifications apportées aux fichiers (HTML, CSS, JavaScript et images) que vous utilisez pour afficher l'interface de l'application. Il peut s'agir, par exemple, d'un changement dans la logique de votre application, d'une image faisant partie de votre interface ou d'une feuille de style CSS.

Mettre à jour les modèles

Voici quelques modèles courants de gestion des mises à jour d'applications, mais vous pouvez toujours personnaliser le processus en fonction de vos besoins:

  • Mise à jour complète: chaque modification, même mineure, déclenche le remplacement de l'ensemble du contenu du cache. Ce schéma imite la manière dont les applications spécifiques à l'appareil gèrent les mises à jour. Il consomme davantage de bande passante et prend plus de temps.
  • Mise à jour des éléments modifiés: seuls les éléments qui ont été modifiés depuis la dernière mise à jour sont remplacés dans le cache. Il est souvent implémenté à l'aide d'une bibliothèque telle que Workbox. Cela implique de créer une liste de fichiers mis en cache, une représentation de hachage du fichier et des codes temporels. À l'aide de ces informations, le service worker compare cette liste avec les éléments mis en cache et choisit ceux à mettre à jour.
  • Mise à jour d'éléments individuels: chaque élément est mis à jour individuellement lorsqu'il est modifié. La stratégie "obsolète lors de la revalidation" décrite dans le chapitre "Diffusion" est un exemple de mise à jour individuelle des éléments.

Quand effectuer la mise à jour

Une autre bonne pratique consiste à trouver le bon moment pour rechercher les mises à jour et les appliquer. Vous avez le choix entre différentes options :

  • Lorsque le service worker se réveille. Il n'y a aucun événement à écouter pour le moment, mais le navigateur exécutera tout code dans le champ d'application global du service worker à son activation.
  • Dans le contexte de la fenêtre principale de votre PWA, après le chargement de la page par le navigateur, pour éviter de ralentir le chargement de l'application.
  • Lorsque des événements en arrière-plan sont déclenchés, par exemple lorsque votre PWA reçoit une notification push ou une synchronisation en arrière-plan Vous pouvez alors mettre à jour votre cache. Vos utilisateurs disposeront alors de la nouvelle version de l'asset la prochaine fois qu'ils ouvriront l'application.

Infos en direct

Vous pouvez également choisir d'appliquer la mise à jour lorsque l'application est ouverte (en ligne) ou fermée. Avec l'approche fermée, même si l'application a téléchargé de nouveaux assets, elle n'apportera aucune modification et utilisera les nouvelles versions lors du prochain chargement.

Une "mise à jour en direct" signifie que dès que l'élément est mis à jour dans le cache, votre PWA le remplace dans le chargement actuel. Il s'agit d'une tâche complexe qui n'est pas abordée dans ce cours. livereload-js et l'API CSSStyleSheet.replace() sont des outils qui facilitent l'implémentation de cette mise à jour.

Mettre à jour le service worker

Le navigateur déclenche un algorithme de mise à jour lorsque votre service worker ou ses dépendances changent. Le navigateur détecte les mises à jour à l'aide d'une comparaison octet par octet entre les fichiers mis en cache et les ressources provenant du réseau.

Le navigateur tente ensuite d'installer la nouvelle version du service worker, et le nouveau service worker est à l'état Waiting (En attente), comme décrit dans le chapitre Service worker. La nouvelle installation exécutera l'événement install pour le nouveau service worker. Si vous mettez en cache des éléments dans ce gestionnaire d'événements, ceux-ci seront également mis en cache à nouveau.

Détecter les modifications des service workers

Pour détecter qu'un nouveau service worker est prêt et installé, nous utilisons l'événement updatefound de l'enregistrement du service worker. Cet événement est déclenché lorsque le nouveau service worker lance l'installation. Nous devons attendre que son état passe à installed avec l'événement statechange. Consultez les informations suivantes:

async function detectSWUpdate() {
  const registration = await navigator.serviceWorker.ready;

  registration.addEventListener("updatefound", event => {
    const newSW = registration.installing;
    newSW.addEventListener("statechange", event => {
      if (newSW.state == "installed") {
         // New service worker is installed, but waiting activation
      }
    });
  })
}

Forcer le forçage

Le nouveau service worker sera installé, mais en attente d'activation par défaut. L'attente empêche le nouveau service worker de prendre en charge d'anciens clients susceptibles d'être incompatibles avec la nouvelle version.

Même si cela n'est pas recommandé, le nouveau service worker peut ignorer ce délai d'attente et lancer l'activation immédiatement.

self.addEventListener("install", event => {
   // forces a service worker to activate immediately
   self.skipWaiting();
  });

self.addEventListener("activate", event => {
  // when this SW becomes activated, we claim all the opened clients
  // they can be standalone PWA windows or browser tabs
  event.waitUntil(clients.claim());
});

L'événement controllerchange se déclenche lorsque le service worker contrôlant la page actuelle change. Par exemple, un nouveau worker a ignoré l'attente et est devenu le nouveau worker actif.

navigator.serviceWorker.addEventListener("controllerchange", event => {
   // The service worker controller has changed
 });

Mettre à jour les métadonnées

Vous pouvez également mettre à jour les métadonnées de votre application, qui sont principalement définies dans le fichier manifeste de l'application Web. Par exemple, mettez à jour son icône, son nom ou son URL de démarrage, ou ajoutez une nouvelle fonctionnalité comme des raccourcis d'application. Mais que se passe-t-il pour tous les utilisateurs qui ont déjà installé l'application avec l'ancienne icône sur leurs appareils ? Comment et quand obtient-il la version mise à jour ?

La réponse dépend de la plate-forme. Voyons les options disponibles.

Safari sur les navigateurs iOS, iPadOS et Android

Sur ces plates-formes, le seul moyen d'obtenir les nouvelles métadonnées du fichier manifeste consiste à réinstaller l'application depuis le navigateur.

Google Chrome sur Android avec WebAPK

Lorsque l'utilisateur a installé votre PWA sur Android à l'aide de Google Chrome après avoir activé WebAPK (c'est-à-dire la plupart des installations de PWA Chrome), la mise à jour est détectée et appliquée en fonction d'un algorithme. Pour en savoir plus, consultez cet article sur les mises à jour du fichier manifeste.

Remarques supplémentaires sur le processus:

Si l'utilisateur n'ouvre pas votre PWA, son APK Web ne sera pas mis à jour. Si le serveur ne renvoie pas le fichier manifeste (erreur 404), Chrome ne recherche pas les mises à jour pendant au moins 30 jours, même si l'utilisateur ouvre la PWA.

Accédez à about:webapks dans Chrome sur Android pour consulter l'état de l'indicateur "Nécessite une mise à jour" et demander une mise à jour. Pour en savoir plus sur cet outil de débogage, consultez le chapitre Outils et débogage.

Samsung Internet sur Android avec WebAPK

Le processus est semblable à celui de la version Chrome. Dans ce cas, si le fichier manifeste de la PWA nécessite une mise à jour, l'APK Web sera mis à jour sur le Wi-Fi au cours des prochaines 24 heures après la création du WebAPK mis à jour.

Google Chrome et Microsoft Edge sur ordinateur

Sur les ordinateurs, lorsque la PWA est lancée, le navigateur détermine la dernière fois où il a recherché des modifications dans le fichier manifeste local. Si le fichier manifeste n'a pas été examiné depuis le dernier démarrage du navigateur ou s'il n'a pas été vérifié au cours des dernières 24 heures, le navigateur envoie une requête réseau pour le fichier manifeste, puis le compare à la copie locale.

Lorsque les propriétés sélectionnées sont mises à jour, une mise à jour est déclenchée une fois toutes les fenêtres fermées.

Alerter l'utilisateur

Certaines stratégies de mise à jour nécessitent une actualisation ou une nouvelle navigation depuis les clients. Vous devez informer l'utilisateur qu'une mise à jour est en attente, mais lui donner la possibilité de mettre à jour la page au moment qui lui convient le mieux.

Pour informer l'utilisateur, vous disposez des options suivantes:

  • Utilisez le DOM ou l'API Canvas pour afficher une notification à l'écran.
  • utiliser l'API Web Notifications ; Cette API fait partie de l'autorisation push permettant de générer une notification dans le système d'exploitation. Pour l'utiliser, vous devez demander l'autorisation Web push, même si vous n'utilisez pas le protocole de messagerie push à partir de votre serveur. C'est la seule option disponible si la PWA n'est pas ouverte.
  • Utilisez l'API Badging pour indiquer que des mises à jour sont disponibles via l'icône d'installation de la PWA.

Notification de mise à jour affichée dans le DOM.

En savoir plus sur l'API Badging

L'API de badge vous permet d'ajouter un numéro de badge à l'icône de votre PWA (ou un point du badge sur les navigateurs compatibles). Un point du badge est une petite marque à l’intérieur de l’icône installée qui exprime un élément attendu dans l’application.

Exemple de Twitter avec huit notifications et une autre application affichant un badge de type drapeau.

Vous devez appeler setAppBadge(count) sur l'objet navigator pour définir un numéro de badge. Vous pouvez le faire depuis la fenêtre ou le contexte du service worker lorsque vous savez qu'une mise à jour est disponible pour alerter l'utilisateur.

let unreadCount = 125;
navigator.setAppBadge(unreadCount);

Pour effacer le badge, appelez clearAppBadge() sur le même objet:

navigator.clearAppBadge();

Ressources