Construire un PWA avec Webpack et Workbox

Est-ce que cela fonctionne hors ligne?

Simulons une mise hors ligne! Ouvrez DevTools, accédez à l’onglet Réseau et cochez la case "Hors ligne". Lorsque vous rechargerez la page, vous constaterez que nous obtiendrons la page hors connexion du navigateur.

C’est parce que la demande initiale de / (qui chargera le fichier index.html ) échouera car Internet est hors ligne. Le seul moyen pour nous de remédier à cette défaillance de la requête consiste à faire appel à un technicien de maintenance.

Visualisons la requête sans technicien de maintenance:

Un prestataire de services est un proxy réseau programmable, ce qui signifie qu'il se situe entre votre page Web et Internet. Cela vous permet de contrôler les requêtes réseau entrantes et sortantes.

Cela est utile car nous pouvons maintenant réacheminer cette demande échouée vers la mémoire cache (en supposant que nous ayons le contenu dans

Un travailleur de service est également un type de travailleur Web, ce qui signifie qu'il est séparé de votre page principale et qu'il ne fonctionne pas. avoir accès à l'objet du document du document ou du document .

Précachez le shell d'application

Pour que notre application fonctionne en mode hors connexion, nous allons commencer par fixer le app shell.

Commençons donc par installer le plugin Webpack Workbox:

 npm install --save-dev workbox-webpack-plugin

Ensuite, nous allons ouvrir notre fichier index.js et enregistrer le technicien:

 if ("serviceWorker" dans le navigateur) {
window.addEventListener ("load", () => {
navigator.serviceWorker.register ("/ sw.js");
})
}

Ensuite, ouvrez le fichier webpack.config.js et configurons le plug-in Workbox Webpack:

 // ajoute en haut de la page
const WorkboxWebpackPlugin = require ("plug-in de workbox-webpack");

// ajoute à l'intérieur du tableau de plugins:
plugins: [
…
, new WorkboxWebpackPlugin.InjectManifest({
  swSrc: "./src/src-sw.js",
  swDest: "sw.js"
})
]

Ceci demandera à Workbox d'utiliser notre fichier ./src / src-sw.js comme base. Le fichier généré s'appellera sw.js et sera placé dans le dossier dist .

Créez ensuite un ./ src / src-sw.js fichier au niveau racine et écrivez ce qui suit à l'intérieur:

 workbox.precaching.precacheAndRoute (self .__ precacheManifest);

Note : La variable self .__ precacheManifest sera importée d'un fichier qui sera généré dynamiquement par la boîte de travail.

Vous êtes prêt maintenant. pour construire votre code avec npm run build et Workbox générera deux fichiers dans le dossier dist :

• precache-manifest.66cf63077c7e4a70ba741ee9e6a8da29.js [1965907] [1965907] sw.js

Le sw.js importe la boîte de travail de CDN ainsi que le precache-manifest. [chunkhash] .js .

 // precache-manifeste. [chunkhash] fichier .js
self .__ precacheManifest = (self .__ precacheManifest || []). concat ([
  
    "revision": "ba8f7488757693a5a5b1e712ac29cc28",
    "url": "index.html"
  },
  
    "url": "main.49467c51ac5e0cb2b58e.js"
  
]);

Le manifeste de pré-cache répertorie les noms des fichiers traités par webpack et qui se retrouvent dans votre dossier dist . Nous allons utiliser ces fichiers pour les mettre en cache dans le navigateur. Cela signifie que lorsque votre site Web se charge pour la première fois et enregistre l'agent de service, il stockera ces actifs dans un cache afin qu'ils puissent être utilisés la prochaine fois.

Vous pouvez également remarquer que certaines entrées ont une "révision", tandis que d'autres ne le font pas. t. C’est parce que la révision peut parfois être déduite du chunkhash du nom de fichier. Par exemple, examinons de plus près le nom du fichier main.49467c51ac5e0cb2b58e.js . Il a une révision dans le nom du fichier, qui est le chunkhash 49467c51ac5e0cb2b58e .

Cela permet à Workbox de comprendre le moment où vos fichiers sont modifiés, de sorte qu'il ne nettoie ou ne mette à jour que les fichiers modifiés. tout le cache à chaque fois que vous publiez une nouvelle version de votre service worker.

La première fois que vous chargez la page, le service maintenance sera installé. Vous pouvez le voir dans DevTools. Tout d'abord, le fichier sw.js est demandé, qui demande ensuite tous les autres fichiers. Elles sont clairement identifiées par l’icône représentant une roue dentée.

Donc, Workbox s’initialisera et mettra en cache tous les fichiers qui se trouvent dans le manifeste de pré-cache. Il est important de vérifier que vous n'avez aucun fichier inutile dans le fichier precache-manifest tel que les fichiers .map ou les fichiers ne faisant pas partie du shell de l'application. 19659003] Dans l'onglet Réseau, nous pouvons voir les demandes provenant du service worker. Et maintenant, si vous essayez de vous déconnecter, le shell de l'application est déjà précaché, de sorte que cela fonctionne même si nous sommes hors ligne!

Cache Dynamic Routes

Avez-vous remarqué que, lorsque nous sommes passés hors ligne, le shell de l'application fonctionne, mais pas nos données? C’est parce que ces appels d’API ne font pas partie du shell d’application précachée précachée . En l'absence de connexion Internet, ces demandes échoueront et l'utilisateur ne pourra pas voir les informations sur la devise.

Cependant, ces demandes ne peuvent pas être précachées, car leur valeur provient d'une API. De plus, lorsque vous commencez à avoir plusieurs pages, vous ne souhaitez pas mettre en cache toutes les demandes d’API en une seule fois. Au lieu de cela, vous souhaitez les mettre en cache lorsque l'utilisateur visite cette page.

Nous les appelons «données dynamiques». Elles incluent souvent des appels d’API ainsi que des images et autres éléments demandés lorsqu’un utilisateur effectue certaines actions sur votre site Web (par exemple, lorsqu'il navigue vers une nouvelle page).

Vous pouvez les mettre en cache à l’aide du module de routage de Workbox. Voici comment:

 // ajouter src / src-sw.js
workbox.routing.registerRoute (
  /https://api.exchangeratesapi.io/latest/,
  new workbox.strategies.NetworkFirst ({
    cacheName: "monnaies",
    plugins: [
      new workbox.expiration.Plugin ({
        maxAgeSeconds: 10 * 60 // 10 minutes
      })
    
  })
)

Ceci va configurer la mise en cache dynamique pour toute URL de requête qui correspond à l'URL https://api.exchangeratesapi.io/latest .

La stratégie de mise en cache que nous avons utilisée ici s'appelle . NetworkFirst ;

1. CacheFirst
2. StaleWhileRevalidate

CacheFirst va d'abord le rechercher dans la cache. S'il n'est pas trouvé, il l'obtiendra du réseau. StaleWhileRevalidate ira au réseau et au cache en même temps. Renvoyer la réponse du cache à la page (en arrière-plan), il utilisera la nouvelle réponse du réseau pour mettre à jour le cache lors de sa prochaine utilisation.

Pour notre cas d'utilisation, nous avons dû utiliser NetworkFirst parce que nous avons affaire à des taux de change qui changent très souvent. Cependant, lorsque l'utilisateur se déconnecte, on peut au moins lui montrer les tarifs tels qu'ils étaient il y a 10 minutes - c'est pourquoi nous avons utilisé le plug-in d'expiration avec le paramètre maxAgeSeconds défini sur 10 * 60 secondes.

Gérer les mises à jour des applications

Chaque fois qu'un utilisateur charge votre page, le navigateur exécute le code navigator.serviceWorker.register même si l'agent de service est déjà installé et en cours d'exécution. Cela permet au navigateur de détecter s’il existe une nouvelle version du service worker. Lorsque le navigateur constate que le fichier n'a pas changé, il ignore simplement l'appel d'enregistrement. Une fois que ce fichier a été modifié, le navigateur a compris qu'il existe une nouvelle version du service worker et il installe donc le nouveau service worker parallèlement au service worker en cours d'exécution .

Cependant, il s'arrête en même temps que le . ] phase installée / en attente car un seul technicien peut être activé à la fois.

Ce n'est que lorsque toutes les fenêtres du navigateur contrôlées par l'ancien ouvrier de service sont installées que l'activation du nouvel ouvrier de service devient sans danger.

Vous pouvez également contrôler manuellement cela en appelant skipWaiting () (ou self.skipWaiting () puisque self correspond au contexte global d'exécution du prestataire de services). Cependant, la plupart du temps, vous ne devriez le faire qu'après avoir demandé à l'utilisateur s'il souhaitait obtenir la dernière mise à jour.

Heureusement, la fenêtre de travail nous aide à atteindre cet objectif. C’est une nouvelle bibliothèque de fenêtres introduite dans Workbox v4 dans le but de simplifier les tâches courantes côté fenêtre.

Commençons par l’installer avec les éléments suivants:

 npm install workbox-window

Ensuite, importez la boîte de travail en haut du fichier index.js :

 import {Workbox} à partir de "workbox-window";

Ensuite, nous remplacerons notre code d’enregistrement par le suivant:

 if ("serviceWorker" dans le navigateur) {
  window.addEventListener ("load", () => {
      const wb = new Workbox ("/ sw.js");
    
wb.register ();
  });

}

Nous allons ensuite trouver le bouton de mise à jour portant l'ID app-update et écouter l'événement workbox-waiting :

 // ajouter avant le wb.register ()
const updateButton = document.querySelector ("# app-update");
// Se déclenche lorsque le technicien de service inscrit est installé mais attend pour l'activer.
wb.addEventListener ("waiting", event => {
    updateButton.classList.add ("show");
    updateButton.addEventListener ("click", () => {
    // Configurez un écouteur qui rechargera la page dès que le prestataire de service précédemment en attente aura pris le contrôle.
    wb.addEventListener ("controlling", événement => {
        window.location.reload ();
    });

    // Envoyer un message demandant au technicien de service d’attendre l’attente.
    // Ceci déclenchera le gestionnaire d'événements `controlling` ci-dessus.
    wb.messageSW ({type: "SKIP_WAITING"});
    });
});

Ce code affichera le bouton de mise à jour lorsqu’il y aura une nouvelle mise à jour (ainsi lorsque le technicien sera en attente) et enverra un message SKIP_WAITING au technicien.

besoin de mettre à jour le fichier d'opérateur de service et de gérer l'événement SKIP_WAITING tel qu'il appelle l'événement skipWaiting :

 // ajouter in src-sw.js
addEventListener ("message", event => {
  if (event.data && event.data.type === "SKIP_WAITING") {
    skipWaiting ();
  
});

Maintenant, lancez npm run dev puis rechargez la page. Allez dans votre code et mettez à jour le titre de la barre de navigation en «Navbar v2». Rechargez à nouveau la page et vous devriez pouvoir voir l'icône de mise à jour.

Enveloppant

Notre site web fonctionne maintenant hors connexion et permet d'avertir l'utilisateur des nouvelles mises à jour. Gardez toutefois à l'esprit que le facteur le plus important lors de la création d'un PWA est l'expérience utilisateur. Concentrez-vous toujours sur la création d’expériences faciles à utiliser par vos utilisateurs. En tant que développeurs, nous avons tendance à être trop enthousiastes face à la technologie et finissons souvent par oublier nos utilisateurs.

Si vous souhaitez aller plus loin, vous pouvez ajouter un manifeste d'application Web qui permettra à vos utilisateurs d'ajouter le site à leur écran d'accueil. Et si vous souhaitez en savoir plus sur Workbox, vous pouvez trouver la documentation officielle sur le site Web Workbox .

Pour en savoir plus sur SmashingMag:

] (dm, yk, il)