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

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

Dans le cycle de développement local typique, les développeurs enregistrent les modifications apportées aux fichiers dans un éditeur de texte, puis basculez vers le navigateur pour vérifier les modifications. Le processus se répète. Lorsqu'un service worker est inclus dans le mix, ce cycle est sensiblement le même. mais il peut y avoir des différences entre ce qu’attend le développeur et ce que fait le navigateur.

Exceptions pour le développement local

En général, les API Service Workers ne sont disponibles que sur les pages HTTPS, mais il existe des exceptions à cette règle où ils peuvent être disponibles via HTTP. La seule exception notable concerne les pages diffusées par localhost, qui fonctionne bien pour le développement local.

Cependant, il n'est pas rare pour les développeurs de spécifier des noms d'hôte locaux autres que localhost dans un hosts. 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é est suffisant.

Une solution plus pratique consiste à demander au navigateur de faire des exceptions pour les tests des service workers. Pour Chrome, accédez à chrome://flags/#unsafely-treat-insecure-origin-as-secure. et spécifier des 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 dans about:config.

Aides au développement pour les service workers

Un développement local impliquant un service worker peut entraîner des comportements apparemment inattendus. Par exemple, imaginons qu'une stratégie de mise en cache uniquement soit en place pour les éléments statiques dont la gestion n'a pas de version, ou une stratégie de mise en cache "vous êtes hors connexion" en pré-cache. qui devrait se mettre à 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, il semble ne jamais être mis à jour ! Aussi frustrant que cela soit, le service worker ne fait que ce pour quoi il a été conçu, mais il existe des moyens de faciliter les tests.

De loin, le moyen le plus efficace de tester un service worker consiste à utiliser des fenêtres de navigation privée, telles que les fenêtres de navigation privée dans Chrome. ou la fonctionnalité de navigation privée de Firefox. Chaque fois que vous ouvrez une fenêtre de navigation privée, vous repartez de 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.

Ce processus vous permet d'imiter fidèlement le cycle de vie d'un service worker.

Autres outils de test disponibles dans le panneau d'application des outils pour les développeurs Chrome peuvent être utiles, même s'ils peuvent modifier le cycle de vie d'un service worker d'une manière ou d'une autre.

Ce panneau comporte un sous-panneau intitulé Service workers, qui affiche les service workers actifs pour la page actuelle. Chaque service worker actif peut être mis à jour manuellement, voire complètement désenregistré. Trois boutons en haut de l'écran facilitent également le développement.

1. L'option Hors connexion simule des conditions hors connexion. Cela facilite le test afin de savoir si un service worker actif diffuse du contenu hors connexion.
2. Mettre à jour lors de l'actualisation: lorsque cette option est activée, cette option récupère et remplace le service worker actuel chaque fois que la page est actualisée.
3. L'option Ignorer pour le réseau, en cas d'activation/de désactivation, 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 sont utiles, en particulier Ignorer pour le réseau, ce qui est très utile lorsque vous développez un projet avec un service worker actif, tout en veillant à ce que l'expérience fonctionne comme prévu sans service worker.

Firefox dispose d'un panneau d'application similaire dans ses outils de développement, mais la fonctionnalité se limite à montrer quels service workers sont installés, ainsi que la possibilité d'annuler manuellement l'enregistrement des service workers actifs pour la page actuelle. Elle est tout aussi utile, mais nécessite davantage d'efforts manuels dans le cycle de développement local.

Maj et actualiser

Lorsque vous développez localement 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 pour le réseau. Lorsqu'un service worker est actif, une actualisation forcée contourne également complètement le service worker.

Cette fonctionnalité est très utile en cas d'incertitude sur le fonctionnement d'une stratégie de mise en cache particulière. Il est utile de tout récupérer sur le réseau pour comparer les comportements avec et sans service worker. Mieux encore, il s'agit d'un comportement spécifique : tous les navigateurs compatibles avec les service workers l'observeront.

Inspecter le contenu du cache

Il est difficile de savoir si une stratégie de mise en cache fonctionne comme prévu lorsque 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, alors qu'un outil visuel serait mieux adapté à la tâche. Le panneau "Application" des outils pour les développeurs Chrome propose un sous-panneau qui permet d'inspecter le contenu des instances Cache.

Ce sous-panneau facilite le développement des service workers en proposant les fonctionnalités suivantes:

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

Cette interface utilisateur graphique permet d'inspecter plus facilement les caches d'un service worker pour voir si des éléments ont été ajoutés, mis à jour ou supprimés du cache d'un 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 (comme des images haute résolution), les quotas de stockage peuvent être atteints. Dans ce cas, le navigateur évince du cache les éléments qu'il considère comme obsolètes ou dignes d'être sacrifiés pour faire de la place à de nouveaux éléments.

La gestion des quotas de stockage devrait faire partie du développement des service workers, et Workbox rend ce processus plus simple que de le gérer vous-même. Toutefois, avec ou sans Workbox, il peut être judicieux de simuler un quota de stockage personnalisé pour tester la logique de gestion du cache.

Le panneau "Application" des outils de développement de Chrome comporte un sous-panneau Stockage qui indique la part du quota de stockage actuellement utilisée par la page. Elle permet également de spécifier un quota personnalisé en mégaoctets. Dès lors, Chrome appliquera le quota de stockage personnalisé afin qu'il puisse être testé.

À titre d'information, ce sous-panneau contient également un bouton Effacer les données du site ainsi qu'une série de cases à cocher associées aux éléments à effacer lorsque l'utilisateur clique dessus. Parmi ces éléments, citons les instances Cache ouvertes et la possibilité d'annuler l'enregistrement des service workers actifs qui contrôlent la page.

Développement simplifié, meilleure productivité

Lorsque les développeurs ne sont pas encombrés, ils peuvent travailler en toute confiance et être plus productifs. Le développement local avec un service worker peut être nuancé, mais ne doit pas nécessairement être laborieux. Grâce à ces conseils et astuces, développer avec un service worker actif devrait être beaucoup plus transparent et prévisible, ce qui améliore l'expérience des développeurs.