Améliorer l'expérience de développement des service workers

Bien que le cycle de vie des service workers assure un processus d'installation et de mise à jour prévisible, il peut rendre le cycle de développement local un peu plus nuancé.

Au cours d'un cycle de développement local classique, les développeurs enregistrent les modifications apportées aux fichiers dans un éditeur de texte, puis passent au navigateur pour vérifier les modifications. Le processus se répète. Lorsqu'un service worker fait l'objet d'une combinaison, ce cycle est globalement le même, mais il peut y avoir des différences entre les attentes du développeur et les actions du navigateur.

Exceptions pour le développement local

En général, les API de service worker ne sont disponibles que sur les pages HTTPS, mais il existe des exceptions à cette règle lorsqu'elles peuvent l'être via HTTP. La seule exception concerne les pages diffusées sur plus de localhost, qui sont adaptées au développement local.

Toutefois, il n'est pas rare que les développeurs spécifient des noms d'hôte locaux en dehors de localhost dans un fichier d'hôtes. Cette étape est obligatoire dans les environnements de développement locaux lorsque plusieurs projets nécessitent des noms d'hôte distincts. Dans ce cas, le provisionnement d'un certificat autosigné suffit.

Une solution plus pratique consiste à demander au navigateur de créer des exceptions pour les tests des service workers. Dans Chrome, accédez à chrome://flags/#unsafely-treat-insecure-origin-as-secure et spécifiez les origines non sécurisées à traiter comme des origines sécurisées. Firefox permet de tester les service workers sur des origines non sécurisées via le paramètre devtools.serviceWorkers.testing.enabled de about:config.

Aide au développement pour les service workers

Le développement local avec un service worker peut entraîner des comportements apparemment inattendus. Prenons l'exemple suivant : une stratégie de mise en cache uniquement est en place pour les éléments statiques sans version ou une page "Vous êtes hors connexion" mise en cache en pré-mise en cache et qui est censée être mise à jour lors de l'actualisation après avoir apporté des modifications. Étant donné qu'une version obsolète de ces éléments est toujours diffusée à partir d'une instance Cache, ils ne sont apparemment jamais mis à jour. Aussi frustrant que cela, le service worker ne fait que ce pour quoi il a été conçu, mais il existe des moyens de faciliter les tests.

Le moyen le plus efficace de tester un service worker consiste de loin à utiliser des fenêtres de navigation privée, telles que les fenêtres de navigation privée de Chrome, ou la fonctionnalité de navigation privée de Firefox. Chaque fois que vous ouvrez une fenêtre de navigation privée, vous recommencez à zéro. Il n'y a aucun service worker actif, ni aucune instance Cache ouverte. La routine pour ce type de test est la suivante:

1. Ouvrez une fenêtre de navigation privée.
2. Accédez à une page qui enregistre un service worker.
3. Vérifiez si le service worker se comporte comme prévu.
4. Fermez la fenêtre de navigation privée.
5. Recommencez.

Avec ce processus, vous imitez fidèlement le cycle de vie d'un service worker.

D'autres outils de test disponibles dans le panneau de l'application Outils pour les développeurs Chrome peuvent vous aider, mais ils peuvent modifier le cycle de vie des service workers de différentes manières.

Le panneau de l'application comporte un sous-panneau intitulé Service workers qui affiche les service workers actifs pour la page active. Chaque service worker actif peut être mis à jour manuellement, voire annulé complètement. Trois boutons d'activation et de désactivation, situés en haut de la page, facilitent le développement.

1. L'option Hors connexion simule les conditions hors connexion. Cela permet de tester si un service worker actif diffuse du contenu hors connexion.
2. Mettre à jour lors de l'actualisation: lorsque l'option est activée, elle récupère et remplace le service worker actuel chaque fois que la page est rechargée.
3. Contournement pour le réseau : lorsque cette option est activée, contourne tout code dans l'événement fetch d'un service worker et récupère toujours du contenu sur le réseau.

Ces boutons d'activation/de désactivation sont utiles, en particulier Contourner pour le réseau, ce qui est idéal lorsque vous développez un projet avec un service worker actif, mais que vous souhaitez également vous assurer que l'expérience fonctionne comme prévu sans service worker.

Firefox propose un panneau d'application similaire dans ses outils pour les développeurs, mais la fonctionnalité se limite à afficher les service workers installés, ainsi que la possibilité d'annuler manuellement l'enregistrement de tout service worker actif sur la page actuelle. Elle est tout aussi utile, mais elle nécessite davantage d'efforts manuels au cours du cycle de développement local.

Maj et actualiser

Lorsque vous développez en local avec un service worker actif, sans avoir besoin des fonctionnalités fournies par la mise à jour lors de l'actualisation ou le contournement pour le réseau, il est également utile de maintenir la touche Maj enfoncée et d'appuyer sur le bouton d'actualisation.

C'est ce qu'on appelle une actualisation forcée, qui contourne le cache HTTP du réseau. Lorsqu'un service worker est actif, l'actualisation forcée le contourne également complètement.

Cette fonctionnalité est particulièrement utile en cas de doute quant au bon fonctionnement d'une stratégie de mise en cache. Elle est utile de tout récupérer depuis le réseau pour comparer les comportements avec et sans service worker. Mieux encore, il s'agit d'un comportement spécifique que tous les navigateurs compatibles avec les service workers observeront.

Inspecter le contenu du cache

Il est difficile de savoir si une stratégie de mise en cache fonctionne comme prévu si le cache ne peut pas être inspecté. Bien sûr, le cache pourrait être inspecté dans le code, mais il s'agit d'un processus impliquant des débogueurs et/ou des instructions console lorsqu'un outil visuel serait plus adapté à la tâche. Le panneau "Application" des outils pour les développeurs Chrome comporte un sous-panneau permettant d'inspecter le contenu des instances Cache.

Ce sous-panneau facilite le développement des service workers grâce à des fonctionnalités telles que:

• Affichez le nom des instances Cache.
• Possibilité d'inspecter le corps de réponse des éléments mis en cache et les en-têtes de réponse associés.
• Évincer un ou plusieurs éléments du cache, ou même supprimer des instances Cache entières.

Cette interface utilisateur graphique permet d'inspecter plus facilement les caches des service workers pour voir si des éléments ont été ajoutés, mis à jour ou complètement supprimés d'un cache de service worker. Firefox propose son propre lecteur de cache, avec des fonctionnalités similaires, bien qu'il se trouve dans un panneau Stockage distinct.

Simuler un quota de stockage

Sur les sites Web comportant de nombreux éléments statiques volumineux (tels que des images haute résolution), il est possible d'atteindre les quotas de stockage. Dans ce cas, le navigateur évince les éléments du cache qu'il juge obsolètes ou qui méritent d'être sacrifiés pour faire de la place à de nouveaux éléments.

La gestion des quotas de stockage doit faire partie du développement des service workers, et Workbox simplifie ce processus que la gestion vous-même. En revanche, avec ou sans Workbox, il peut être judicieux de simuler un quota de stockage personnalisé pour tester la logique de gestion du cache.

Dans les outils pour les développeurs Chrome, le panneau "Application" comporte un sous-panneau Stockage qui fournit des informations sur la part du quota de stockage actuel utilisée par la page. Elle permet également de spécifier un quota personnalisé en mégaoctets. Une fois en vigueur, Chrome appliquera le quota de stockage personnalisé afin de pouvoir le tester.

Ce sous-panneau contient également un bouton Effacer les données du site et tout un ensemble de cases à cocher associées aux éléments à décocher lorsque l'utilisateur clique dessus. Parmi ces éléments figurent les instances Cache ouvertes et la possibilité d'annuler l'enregistrement des service workers actifs contrôlant la page.

Développement simplifié, productivité accrue

Lorsque les développeurs ne sont pas entravés, ils peuvent travailler de façon plus sereine et être plus productifs. Le développement local avec un service worker peut être nuancé, mais ce n'est pas une mince affaire. Grâce à ces conseils et astuces, le développement avec un service worker actif devrait être beaucoup plus transparent et prévisible, ce qui améliorera l'expérience de développement.