Tutoriel pour les techniciens de service

Les techniciens de service sont une technologie clé qui alimente les applications Web progressives sur le Web mobile. Ils permettent la mise en cache des ressources et les notifications push, deux des principales caractéristiques qui distinguent jusqu'à présent les applications natives.

Introduction aux travailleurs des services

Les travailleurs des services sont au cœur deApplications Web progressives, car ils permettent la mise en cache des ressources et les notifications push, deux des principales caractéristiques qui distinguent jusqu'à présent les applications natives.

Un technicien de service estproxy programmableentre votre page Web et le réseau, offrant la possibilité d'intercepter et de mettre en cache les requêtes réseau de manière efficacevous donnant la possibilité de créer une première expérience hors ligne pour votre application.

C'est une sorte spéciale detravailleur web, uneJavaScriptfichier associé à une page Web qui s'exécute sur un contexte de travail, séparé du thread principal, offrant l'avantage d'être non bloquant - ainsi les calculs peuvent être effectués sans sacrifier la réactivité de l'interface utilisateur.

Étant sur un fil séparé, il n'a pasDOMaccès, et aucun accès auStockage localAPI et leXHRAPI également, et il ne peut communiquer avec le thread principal qu'en utilisant leAPI de messagerie de canal.

Les techniciens de service coopèrent avec d'autres API Web récentes:

Et ils sontuniquement disponible sur HTTPSles pages de protocole, à l'exception des requêtes locales, qui n'ont pas besoin d'une connexion sécurisée pour un test plus facile.

Traitement en arrière-plan

Les techniciens de service s'exécutent indépendamment de l'application à laquelle ils sont associés et peuvent recevoir des messages lorsqu'ils ne sont pas actifs.

Par exemple, ils peuvent fonctionner:

  • lorsque votre application mobile esten arrière-plan, pas actif
  • lorsque votre application mobile estfermé, donc même pas en arrière-plan
  • lorsquele navigateur est fermé, si l'application s'exécute dans le navigateur

Les principaux scénarios dans lesquels les Service Workers sont très utiles sont:

  • ils peuvent être utilisés commecouche de mise en cachepour gérer les demandes réseau et mettre en cache le contenu à utiliser en mode hors connexion
  • autorisernotifications push

Un Service Worker ne s'exécute qu'en cas de besoin, et il est arrêté lorsqu'il n'est pas utilisé.

Assistance hors ligne

Traditionnellement, l'expérience hors ligne des applications Web était très médiocre. Sans réseau, les applications mobiles Web ne fonctionnent souvent pas, tandis que les applications mobiles natives ont la possibilité d'offrir une version fonctionnelle ou une sorte de message agréable.

Ce n'est pas un bon message, mais voici à quoi ressemblent les pages Web dans Chrome sans connexion réseau:

Offline support missing in service workers

Peut-être que la seule chose intéressante à ce sujet est que vous pouvez jouer à un jeu gratuit en cliquant sur le dinosaure, mais cela devient assez vite ennuyeux.

Dinosaur game chrome

Dans un passé récent, HTML5 AppCache promettait déjà d'autoriser les applications Web à mettre en cache des ressources et à travailler hors ligne, mais son manque de flexibilité et son comportement déroutant indiquaient clairement qu'il n'était pas assez bon pour le travail, manquant à ses promesses (etil a été interrompu).

Les Service Workers sont la nouvelle norme pour la mise en cache hors ligne.

Quel type de mise en cache est possible?

Mise en cache des actifs lors de l'installation

Les actifs réutilisés dans toute l'application, tels que les images, les CSS et les fichiers JavaScript, peuvent être installés la première fois que l'application est ouverte.

Cela donne la base de ce qu'on appelle leArchitecture App Shell.

Mise en cache des requêtes réseau

En utilisant leRécupérer l'APInous pouvons éditer la réponse provenant du serveur, déterminer si le serveur n'est pas joignable et fournir une réponse du cache à la place.

Un cycle de vie de service Worker

Un technicien de service passe par 3 étapes pour être pleinement opérationnel:

  • Inscription
  • Installation
  • Activation

Inscription

L'enregistrement indique au navigateur où se trouve le serveur de travail et démarre l'installation en arrière-plan.

Exemple de code pour enregistrer un Service Worker placéworker.js:

if ('serviceWorker' in navigator) {
  window.addEventListener('load', () => {
    navigator.serviceWorker.register('/worker.js')
    .then((registration) => {
      console.log('Service Worker registration completed with scope: ',
        registration.scope)
    }, (err) => {
      console.log('Service Worker registration failed', err)
    })
  })
} else {
  console.log('Service Workers not supported')
}

Même si ce code est appelé plusieurs fois, le navigateur n'effectuera l'enregistrement que si le technicien de service est nouveau, non enregistré précédemment ou s'il a été mis à jour.

Portée

Leregister()call accepte également un paramètre d'étendue, qui est un chemin qui détermine quelle partie de votre application peut être contrôlée par le service worker.

Il utilise par défaut tous les fichiers et sous-dossiers contenus dans le dossier qui contient le fichier du service worker, donc si vous le placez dans le dossier racine, il aura le contrôle sur l'ensemble de l'application. Dans un sous-dossier, il contrôlera uniquement les pages accessibles sous cette route.

L'exemple ci-dessous enregistre le travailleur, en spécifiant le/notifications/portée du dossier.

navigator.serviceWorker.register('/worker.js', {
  scope: '/notifications/'
})

Le/est important: dans ce cas, la page/notificationsne déclenchera pas le Service Worker, alors que si l'étendue était

{
  scope: '/notifications'
}

cela aurait fonctionné.

REMARQUE: Le technicien de service ne peut pas «monter» lui-même à partir d'un dossier: si son fichier est placé sous/notifications, il ne peut pas contrôler le/chemin ou tout autre chemin qui n'est pas sous/notifications.

Installation

Si le navigateur détermine qu'un service worker est obsolète ou n'a jamais été enregistré auparavant, il procédera à son installation.

self.addEventListener('install', (event) => {
  //...
});

C'est un bon événement pour préparer le Service Worker à être utilisé, parinitialiser un cache, etmettre en cache App Shellet les actifs statiques utilisant leAPI de cache.

Activation

L'étape d'activation est la troisième étape, une fois que le technicien de service a été enregistré et installé avec succès.

À ce stade, le technicien de service pourra travailler avec de nouveaux chargements de page.

Il ne peut pas interagir avec les pages déjà chargées, ce qui signifie que le service worker n'est utile que la deuxième fois que l'utilisateur interagit avec l'application ou recharge l'une des pages déjà ouvertes.

self.addEventListener('activate', (event) => {
  //...
});

Un bon cas d'utilisation de cet événement consiste à nettoyer les anciens caches et les éléments associés à l'ancienne version mais inutilisés dans la nouvelle version du service worker.

Mettre à jour un technicien de service

Pour mettre à jour un Service Worker, il vous suffit de modifier un octet dans celui-ci, et lorsque le code de registre est exécuté, il sera mis à jour.

Une fois qu'un Service Worker est mis à jour, il ne devient disponible que lorsque toutes les pages chargées avec l'ancien Service Worker sont fermées.

Cela garantit que rien ne se cassera sur les applications / pages qui fonctionnent déjà.

L'actualisation de la page ne suffit pas, car l'ancien worker est toujours en cours d'exécution et n'a pas été supprimé.

Récupérer les événements

UNErécupérer l'événementest déclenché lorsqu'une ressource est demandée sur le réseau.

Cela nous offre la possibilité deregarde dans le cacheavant de faire des requêtes réseau.

Par exemple, l'extrait ci-dessous utilise leAPI de cachepour vérifier si l'URL de la demande était déjà stockée dans les réponses mises en cache et renvoyer la réponse en cache si tel est le cas. Sinon, il exécute la demande de récupération et la renvoie.

self.addEventListener('fetch', (event) => {
  event.respondWith(
    caches.match(event.request)
      .then((response) => {
        if (response) { //entry found in cache
          return response
        }
        return fetch(event.request)
      }
    )
  )
})

Synchronisation en arrière-plan

La synchronisation en arrière-plan permet de différer les connexions sortantes jusqu'à ce que l'utilisateur dispose d'une connexion réseau opérationnelle.

Ceci est essentiel pour garantir qu'un utilisateur peut utiliser l'application hors ligne, effectuer des actions dessus, et mettre en file d'attente les mises à jour côté serveur lorsqu'une connexion est ouverte, au lieu de montrer un rouet sans fin essayant d'obtenir un signal.

navigator.serviceWorker.ready.then((swRegistration) => {
  return swRegistration.sync.register('event1')
});

Ce code écoute l'événement dans le Service Worker:

self.addEventListener('sync', (event) => {
  if (event.tag == 'event1') {
    event.waitUntil(doSomething())
  }
})

doSomething()renvoie une promesse. En cas d'échec, un autre événement de synchronisation sera planifié pour réessayer automatiquement, jusqu'à ce qu'il réussisse.

Cela permet également à une application de mettre à jour les données du serveur dès qu'une connexion fonctionnelle est disponible.

Événements push

Les Service Workers permettent aux applications Web de fournir des notifications push natives aux utilisateurs, grâce à l'utilisation de:

Push et Notifications sont en fait deux concepts et technologies différents, mais combinés pour fournir ce que nous appelonsNotifications push. Push fournit le mécanisme qui permet à un serveur d'envoyer des informations à un technicien de service, et les notifications permettent aux techniciens de service d'afficher des informations à l'utilisateur.

Étant donné que les techniciens de service s'exécutent même lorsque l'application n'est pas en cours d'exécution, ils peuvent écouter les événements push à venir et fournir des notifications aux utilisateurs ou mettre à jour l'état de l'application.

Les événements push sont initiés par un backend, via un service push de navigateur, comme celui fourni parFirebase.

Voici un exemple de la façon dont le technicien de service peut écouter les événements push entrants:

self.addEventListener('push', (event) => {
  console.log('Received a push event', event)

const options = { title: ‘I got a message for you!’, body: ‘Here is the body of the message’, icon: ‘/img/icon-192x192.png’, tag: ‘tag-for-this-notification’, }

event.waitUntil( self.registration.showNotification(title, options) ) })

Une note sur les journaux de la console

Si vous avez une instruction de journal de console (console.loget amis) dans le Service Worker, assurez-vous d'activer lePreserve logfonctionnalité fournie par leChrome DevTools, ou équivalent.

Sinon, étant donné que le service worker agit avant le chargement de la page et que la console est effacée avant le chargement de la page, vous ne verrez aucun journal dans la console.

Téléchargez mon gratuitManuel du débutant JavaScript


Plus de didacticiels sur le navigateur: