diff options
Diffstat (limited to 'files/fr/web/api/service_worker_api')
| -rw-r--r-- | files/fr/web/api/service_worker_api/index.html | 20 | ||||
| -rw-r--r-- | files/fr/web/api/service_worker_api/using_service_workers/index.html | 73 |
2 files changed, 45 insertions, 48 deletions
diff --git a/files/fr/web/api/service_worker_api/index.html b/files/fr/web/api/service_worker_api/index.html index 0ef299c60c..76f29f0ca6 100644 --- a/files/fr/web/api/service_worker_api/index.html +++ b/files/fr/web/api/service_worker_api/index.html @@ -14,23 +14,23 @@ translation_of: Web/API/Service_Worker_API <p>{{ SeeCompatTable() }}</p> -<p class="summary">Les service workers jouent essentiellement le rôle de serveurs proxy placés entre une application web, et le navigateur ou le réseau (lorsque disponible.) Ils sont destinés (entre autres choses) à permettre la création d'expériences de navigation déconnectée efficaces, en interceptant les requêtes réseau et en effectuant des actions appropriées selon que le réseau est disponible et que des ressources mises à jour sont à disposition sur le serveur. Ils permettront aussi d'accéder aux APIs de notifications du serveur (push) et de synchronisation en arrière-plan.</p> +<p>Les service workers jouent essentiellement le rôle de serveurs proxy placés entre une application web, et le navigateur ou le réseau (lorsque disponible.) Ils sont destinés (entre autres choses) à permettre la création d'expériences de navigation déconnectée efficaces, en interceptant les requêtes réseau et en effectuant des actions appropriées selon que le réseau est disponible et que des ressources mises à jour sont à disposition sur le serveur. Ils permettront aussi d'accéder aux APIs de notifications du serveur (push) et de synchronisation en arrière-plan.</p> </div> <h2 id="Service_worker_concepts_et_usage">Service worker, concepts et usage</h2> -<p>Un service worker est un <a href="https://developer.mozilla.org/en-US/docs/Web/API/Worker">worker</a> événementiel enregistré auprès d'une origine et d'un chemin. Il prend la forme d'un fichier JavaScript qui peut contrôler la page ou le site web auquel il est associé, en interceptant et en modifiant la navigation et les requêtes de ressources, et en mettant en cache les ressources selon une granularité très fine pour vous donner une maîtrise complète de la manière dont doit se comporter votre application dans certaines situations (l'une des plus évidentes étant l'indisponibilité du réseau.)</p> +<p>Un service worker est un <a href="/en-US/docs/Web/API/Worker">worker</a> événementiel enregistré auprès d'une origine et d'un chemin. Il prend la forme d'un fichier JavaScript qui peut contrôler la page ou le site web auquel il est associé, en interceptant et en modifiant la navigation et les requêtes de ressources, et en mettant en cache les ressources selon une granularité très fine pour vous donner une maîtrise complète de la manière dont doit se comporter votre application dans certaines situations (l'une des plus évidentes étant l'indisponibilité du réseau.)</p> <p>Un service worker fonctionne dans le contexte d'un worker : il n'a donc pas d'accès au DOM, et s'exécute dans une tâche différente de celle du script principal de votre application, ainsi il est non-bloquant. Il est conçu pour être totalement asynchrone; en conséquence, des APIs telles que <a href="/fr/docs/Web/API/XMLHttpRequest">XHR</a> en synchrone et <a href="/fr/docs/Web/API/Web_Storage_API">localStorage</a> ne peuvent pas être utilisées au sein d'un service worker.</p> <p>Les service workers fonctionnent uniquement sur HTTPS, pour des raisons de sécurité. Laisser des requêtes réseau modifiées sans défense face aux attaques de l'homme du milieu est une bien mauvaise chose.</p> <div class="note"> -<p><strong>Remarque </strong>: les service workers ont rallié à eux des tentatives précédemment effectuées dans les mêmes domaines comme l'API <a class="external" href="http://alistapart.com/article/application-cache-is-a-douchebag">AppCache</a> parce qu'ils ne présument pas de ce que vous essayez de faire et ainsi s'interrompent quand ces suppositions ne sont pas tout à fait exactes; tout peut faire l'objet d'un contrôle d'une granularité très fine.</p> +<p><strong>Note :</strong> les service workers ont rallié à eux des tentatives précédemment effectuées dans les mêmes domaines comme l'API <a href="http://alistapart.com/article/application-cache-is-a-douchebag">AppCache</a> parce qu'ils ne présument pas de ce que vous essayez de faire et ainsi s'interrompent quand ces suppositions ne sont pas tout à fait exactes; tout peut faire l'objet d'un contrôle d'une granularité très fine.</p> </div> <div class="note"> -<p><strong>Remarque </strong>: les service workers font un usage intensif des <a href="/fr/docs/Web/JavaScript/Reference/Objets_globaux/Promise" lang="fr">promesses</a>, comme généralement ils sont en attente de réponses, auxquelles ils réagissent alors différemment en cas de succès ou en cas d'erreur. L'architecture des promesses est idéale dans ces situations.</p> +<p><strong>Note :</strong> les service workers font un usage intensif des <a href="/fr/docs/Web/JavaScript/Reference/Objets_globaux/Promise">promesses</a>, comme généralement ils sont en attente de réponses, auxquelles ils réagissent alors différemment en cas de succès ou en cas d'erreur. L'architecture des promesses est idéale dans ces situations.</p> </div> <h3 id="Enregistrement">Enregistrement</h3> @@ -64,7 +64,7 @@ translation_of: Web/API/Service_Worker_API <p>Votre service worker peut répondre aux requêtes en utilisant l'événement {{domxref("FetchEvent")}}. Vous pouvez modifier la réponse à ces requêtes de la manière que vous souhaitez, en utilisant la méthode {{domxref("FetchEvent.respondWith") }}.</p> <div class="note"> -<p><strong>Remarque </strong>: Parce que <code>oninstall</code>/<code>onactivate</code> pourraient prendre du temps à s'exécuter, la spec service worker fournit une méthode <code>waitUntil</code> qui, lorsque <code>oninstall</code> ou <code>onactivate</code> sont appelées, passe une promesse. Les événements fonctionnels ne sont pas envoyés au service worker tant que la promesse n'a pas été résolue avec succès.</p> +<p><strong>Note :</strong> Parce que <code>oninstall</code>/<code>onactivate</code> pourraient prendre du temps à s'exécuter, la spec service worker fournit une méthode <code>waitUntil</code> qui, lorsque <code>oninstall</code> ou <code>onactivate</code> sont appelées, passe une promesse. Les événements fonctionnels ne sont pas envoyés au service worker tant que la promesse n'a pas été résolue avec succès.</p> </div> <p>Pour un tutoriel complet qui montre comment réaliser un premier exemple basique, il est conseillé de lire <a href="/fr/docs/Web/API/Service_Worker_API/Using_Service_Workers">Utiliser les Services Workers</a>.</p> @@ -86,7 +86,7 @@ translation_of: Web/API/Service_Worker_API <p>À l'avenir, les service workers seront capables de réaliser nombre d'autres tâches utiles au sein d'une plate-forme web, ce qui les rapprochera de la viabilité des applications natives. Il est intéressant de noter que d'autres spécifications peuvent ou commencent à faire usage du contexte des service workers, par exemple :</p> <ul> - <li><a class="external" href="https://github.com/slightlyoff/BackgroundSync">Synchronisation en arrière-plan</a> : démarrer un service worker même lorsqu'aucun utilisateur est sur le site, afin de mettre à jour les caches, etc.</li> + <li><a href="https://github.com/slightlyoff/BackgroundSync">Synchronisation en arrière-plan</a> : démarrer un service worker même lorsqu'aucun utilisateur est sur le site, afin de mettre à jour les caches, etc.</li> <li><a href="/fr/docs/Web/API/Push_API">Réagir à des messages de push </a>: démarrer un service worker pour envoyer aux utilisateurs un message leur signalant qu'un nouveau contenu est disponible.</li> <li>Réagir à une date particulière</li> <li>Enregistrer une géo-localisation</li> @@ -165,10 +165,10 @@ translation_of: Web/API/Service_Worker_API <h2 id="Voir_aussi">Voir aussi</h2> <ul> - <li><a class="external" href="https://serviceworke.rs">ServiceWorker Cookbook</a></li> - <li><a href="/fr/docs/Web/API/Service_Worker_API/Using_Service_Workers" lang="fr">Utilisation des Service Workers</a></li> - <li><a class="external" href="https://github.com/mdn/sw-test">Exemple basique de Service workers</a></li> - <li><a class="external" href="https://jakearchibald.github.io/isserviceworkerready/">Is ServiceWorker ready?</a></li> + <li><a href="https://serviceworke.rs">ServiceWorker Cookbook</a></li> + <li><a href="/fr/docs/Web/API/Service_Worker_API/Using_Service_Workers">Utilisation des Service Workers</a></li> + <li><a href="https://github.com/mdn/sw-test">Exemple basique de Service workers</a></li> + <li><a href="https://jakearchibald.github.io/isserviceworkerready/">Is ServiceWorker ready?</a></li> <li><a href="/fr/docs/Web/JavaScript/Reference/Objets_globaux/Promise">Promises</a></li> <li><a href="/fr/docs/Utilisation_des_web_workers">Utilisation des web workers</a></li> </ul> diff --git a/files/fr/web/api/service_worker_api/using_service_workers/index.html b/files/fr/web/api/service_worker_api/using_service_workers/index.html index 8225067a3b..1af137c1f5 100644 --- a/files/fr/web/api/service_worker_api/using_service_workers/index.html +++ b/files/fr/web/api/service_worker_api/using_service_workers/index.html @@ -13,9 +13,7 @@ translation_of: Web/API/Service_Worker_API/Using_Service_Workers <p>{{ SeeCompatTable() }}</p> -<div class="summary"> <p>Cet article fournit des informations pour bien débuter avec les service workers, en présentant une architecture de base, l'inscription d'un service worker, l'installation et l'activation d'un processus pour un nouveau service worker, la mise à jour d'un service worker, le contrôle du cache et la personnalisation des réponses, le tout dans le contexte d'une application de base disponible en mode déconnecté.</p> -</div> <h2 id="Le_préambule_aux_Service_Workers">Le préambule aux Service Workers</h2> @@ -24,7 +22,7 @@ translation_of: Web/API/Service_Worker_API/Using_Service_Workers La première tentative— AppCache — semblait être une bonne idée parce qu'elle permettait de spécifier les ressources à mettre en cache de manière très simple. Cependant, elle faisait beaucoup de suppositions sur la manière de le mettre en place et échouait implacablement si votre application ne se pliait pas exactement à ces suppositions. Lisez <a href="http://alistapart.com/article/application-cache-is-a-douchebag">Application Cache is a Douchebag</a> de Jake Archibald pour plus de détails.</p> <div class="note"> -<p><strong>Remarque </strong>: à partir de Firefox 44, lorsque <a href="/fr/docs/Web/HTML/Utiliser_Application_Cache">AppCache</a> est utilisé pour fournir un support déconnecté à une page, un message d'avertissement est alors affiché dans la console pour signaler aux développeurs d'utiliser plutôt les <a href="/fr/docs/Web/API/Service_Worker_API/Using_Service_Workers">Service workers</a> ({{bug("1204581")}}.)</p> +<p><strong>Note :</strong> à partir de Firefox 44, lorsque <a href="/fr/docs/Web/HTML/Utiliser_Application_Cache">AppCache</a> est utilisé pour fournir un support déconnecté à une page, un message d'avertissement est alors affiché dans la console pour signaler aux développeurs d'utiliser plutôt les <a href="/fr/docs/Web/API/Service_Worker_API/Using_Service_Workers">Service workers</a> ({{bug("1204581")}}.)</p> </div> <p>Les service workers devraient finalement résoudre ces problèmes. La syntaxe du service Worker est plus complexe que celle de l'AppCache, mais en contrepartie vous pouvez utiliser JavaScript pour contrôler les comportements induits par votre cache local avec une granularité beaucoup plus fine, vous permettant ainsi d'adresser ce problème et beaucoup d'autres. Avec l'aide d'un Service Worker, vous pouvez facilement configurer une application pour d'abord utiliser des ressources mises en cache, fournissant ainsi une première expérience par défaut même en mode déconnecté, avant de récupérer davantage de données depuis le réseau (principe connu généralement sous le nom de <a href="http://offlinefirst.org/">Offline First</a>). Cette façon de faire est déjà disponible avec les applications natives, ce qui est l'une des raisons principales de la préférence accordée à ces applications plutôt qu'aux applications web.</p> @@ -43,8 +41,6 @@ translation_of: Web/API/Service_Worker_API/Using_Service_Workers <h2 id="Architecture_de_base">Architecture de base</h2> -<p><img alt="" src="https://mdn.mozillademos.org/files/8241/flowchart-production-version.png" style="float: right; height: 600px; margin-left: 20px; width: 300px;"></p> - <p>Avec les service workers, les étapes suivantes sont généralement observées pour une configuration simple :</p> <ol> @@ -57,6 +53,8 @@ translation_of: Web/API/Service_Worker_API/Using_Service_Workers <li>Le Service Worker contrôle désormais les pages, mais seulement celles ouvertes après que le <code>register()</code> ait réussi. Ainsi un document à sa création s'accompagne ou non d'un Service Worker et conserve cet état tout au long de sa durée de vie. Ainsi les documents devront être rechargés pour réellement être contrôlés.</li> </ol> +<p><img alt="" src="sw-lifecycle.png"></p> + <h3 id="Promesses">Promesses</h3> <p><a href="/fr/docs/Web/JavaScript/Reference/Objets_globaux/Promise">Les Promesses</a> sont un puissant mécanisme pour exécuter des opérations asynchrones, dont le succès de l'une dépend du succès de l'autre. Ce mécanisme est au coeur du fonctionnement des service workers.<br> @@ -67,7 +65,7 @@ translation_of: Web/API/Service_Worker_API/Using_Service_Workers <h4 id="sync">sync</h4> -<pre class="brush: js notranslate">try { +<pre class="brush: js">try { var value = myFunction(); console.log(value); } catch(err) { @@ -76,7 +74,7 @@ translation_of: Web/API/Service_Worker_API/Using_Service_Workers <h4 id="async">async</h4> -<pre class="brush: js notranslate">myFunction().then(function(value) { +<pre class="brush: js">myFunction().then(function(value) { console.log(value); }).catch(function(err) { console.log(err); @@ -89,10 +87,10 @@ translation_of: Web/API/Service_Worker_API/Using_Service_Workers Alternativement, on pourrait faire notre propre promesse pour gérer ce genre de cas. (Voir l'exemple du <a href="https://github.com/mdn/promises-test">test de promesses</a> pour le code source, ou <a href="https://mdn.github.io/promises-test/">le voir fonctionner en direct</a>.)</p> <div class="note"> -<p><strong>Remarque </strong>: la mise en place d'un véritable service worker utiliserait la mise en cache et onfetch plutôt que l'API obsolète XMLHttpRequest. Ces fonctionnalités ne sont pas utilisées ici afin de se concentrer sur la compréhension des promesses.</p> +<p><strong>Note :</strong> la mise en place d'un véritable service worker utiliserait la mise en cache et onfetch plutôt que l'API obsolète XMLHttpRequest. Ces fonctionnalités ne sont pas utilisées ici afin de se concentrer sur la compréhension des promesses.</p> </div> -<pre class="brush: js notranslate">function imgLoad(url) { +<pre class="brush: js">function imgLoad(url) { return new Promise(function(resolve, reject) { var request = new XMLHttpRequest(); request.open('GET', url); @@ -118,7 +116,7 @@ translation_of: Web/API/Service_Worker_API/Using_Service_Workers <p>Lorsqu'on appelle la fonction <code>imgLoad()</code>, on l'appelle avec l'url de l'image à charger, comme on pourrait s'en douter, mais le reste du code est un peu différent :</p> -<pre class="brush: js notranslate">var body = document.querySelector('body'); +<pre class="brush: js">var body = document.querySelector('body'); var myImage = new Image(); imgLoad('myLittleVader.jpg').then(function(response) { @@ -134,22 +132,21 @@ imgLoad('myLittleVader.jpg').then(function(response) { <p>Le tout se déroule de manière asynchrone.</p> <div class="note"> -<p><strong>Remarque </strong>: il est possible d'assembler des appels de promesse, par exemple:<br> +<p><strong>Note :</strong> il est possible d'assembler des appels de promesse, par exemple:<br> <code>myPromise().then(success, failure).then(success).catch(failure);</code></p> </div> <div class="note"> -<p><strong>Remarque </strong>: pour en savoir plus sur les promesses, consulter l'excellent article de Jake Archibald <a href="http://www.html5rocks.com/en/tutorials/es6/promises/">JavaScript Promises: there and back again</a>.</p> +<p><strong>Note :</strong> pour en savoir plus sur les promesses, consulter l'excellent article de Jake Archibald <a href="http://www.html5rocks.com/en/tutorials/es6/promises/">JavaScript Promises: there and back again</a>.</p> </div> <h2 id="Démo_de_service_workers">Démo de service workers</h2> <p>Pour illustrer quelques principes de base de l'enregistrement et de l'installation d'un service worker, voici une simple démo appelée <a href="https://github.com/mdn/sw-test">sw-test</a>, qui présente juste une galerie d'images Star wars Lego. Elle utilise une fonction pilotée par une promesse pour lire les données d'une image à partir d'un objet JSON et charger les images en utilisant Ajax, avant d'afficher les images en bas de page. Les choses restent statiques et simples pour le moment. Elle enregistre aussi, installe et active un service worker, et lorsque la spécification est davantage supportée par les navigateurs, elle met en cache tous les fichiers requis pour un fonctionnement déconnecté !</p> -<p><img alt="" src="https://mdn.mozillademos.org/files/8243/demo-screenshot.png" style="display: block; height: 410px; margin: 0px auto; width: 480px;"><br> - <br> - <br> - Vous pouvez consulter le <a href="https://github.com/mdn/sw-test/">code source sur GitHub</a>, et <a href="https://mdn.github.io/sw-test/">voir l'exemple en direct</a>. Le bout de code qui sera appelé est la promesse (voir <a href="https://github.com/mdn/sw-test/blob/gh-pages/app.js#L17-L42">app.js lines 17-42</a>), qui est une version modifiée du code présenté ci-dessus, dans la <a href="https://github.com/mdn/promises-test">démo du test de promesses</a>. Il en diffère de la façon suivante :</p> +<p><img alt="" src="demo-screenshot.png"></p> + +<p>Vous pouvez consulter le <a href="https://github.com/mdn/sw-test/">code source sur GitHub</a>, et <a href="https://mdn.github.io/sw-test/">voir l'exemple en direct</a>. Le bout de code qui sera appelé est la promesse (voir <a href="https://github.com/mdn/sw-test/blob/gh-pages/app.js#L17-L42">app.js lines 17-42</a>), qui est une version modifiée du code présenté ci-dessus, dans la <a href="https://github.com/mdn/promises-test">démo du test de promesses</a>. Il en diffère de la façon suivante :</p> <ol> <li>Dans l'original, on considère l'URL d'une image à charger. Dans cette version, on passe un fragment JSON contenant toutes les données d'une seule image (voir à quoi il ressemble dans <a href="https://github.com/mdn/sw-test/blob/gh-pages/image-list.js">image-list.js</a>). C'est parce que toutes les données pour que chaque promesse soit résolue doivent être passées avec la promesse, que c'est asynchrone. Si l'on passe juste l'url, et si l'on essaie alors d'accéder aux autres éléments dans le JSON séparément lorsqu'on itère plus tard avec la boucle <code>for()</code>, cela ne marchera pas, puisque la promesse ne se résolvera pas en même temps que les itérations sont faites (c'est un mécanisme synchrone.)</li> @@ -165,7 +162,7 @@ imgLoad('myLittleVader.jpg').then(function(response) { <p>Le premier bloc de code dans le fichier JavaScript de l'application — <code>app.js</code> — se présente comme suit. C'est le point d'entrée pour utiliser des service workers.</p> -<pre class="brush: js notranslate">if ('serviceWorker' in navigator) { +<pre class="brush: js">if ('serviceWorker' in navigator) { navigator.serviceWorker.register('/sw-test/sw.js', { scope: '/sw-test/' }).then(function(reg) { // registration worked console.log('Registration succeeded. Scope is ' + reg.scope); @@ -188,11 +185,11 @@ imgLoad('myLittleVader.jpg').then(function(response) { Un seul service worker peut contrôler de nombreuses pages. Chaque fois qu'une page au sein du scope est chargée, le service worker est installé et opère sur la page. Attention, il faut faire un usage prudent des variables globales dans le script du service worker : chaque page ne dispose pas de son propre et unique worker.</p> <div class="note"> -<p><strong>Remarque </strong>: un service worker fonctionne comme un serveur proxy, permettant de modifier les requêtes et les réponses, de les remplacer par des éléments de son propre cache, et bien plus.</p> +<p><strong>Note :</strong> un service worker fonctionne comme un serveur proxy, permettant de modifier les requêtes et les réponses, de les remplacer par des éléments de son propre cache, et bien plus.</p> </div> <div class="note"> -<p><strong>Remarque </strong>: une chose importante à savoir au sujet des service workers est que si la détection de fonctionnalité est utilisée comme ci-dessus, les navigateurs qui ne supportent pas les service workers peuvent simplement utiliser l'application de la manière normalement attendue. De plus, si vous utilisez AppCache et SW sur une page, les navigateurs qui ne supportent pas SW mais supportent AppCache l'utiliseront, et les navigateurs qui supportent les deux ignoreront AppCache au profit de SW.</p> +<p><strong>Note :</strong> une chose importante à savoir au sujet des service workers est que si la détection de fonctionnalité est utilisée comme ci-dessus, les navigateurs qui ne supportent pas les service workers peuvent simplement utiliser l'application de la manière normalement attendue. De plus, si vous utilisez AppCache et SW sur une page, les navigateurs qui ne supportent pas SW mais supportent AppCache l'utiliseront, et les navigateurs qui supportent les deux ignoreront AppCache au profit de SW.</p> </div> <h4 id="Pourquoi_mon_service_worker_échoue_à_senregistrer">Pourquoi mon service worker échoue à s'enregistrer ?</h4> @@ -212,12 +209,12 @@ imgLoad('myLittleVader.jpg').then(function(response) { L'événement install est déclenché lorsqu'une installation se termine avec succès. L'événement install est généralement utilisé pour remplir le cache local du navigateur avec les ressources nécessaires pour faire fonctionner l'application en mode déconnecté. A cet effet, la toute nouvelle API de stockage est utilisée — {{domxref("cache")}} — un espace global au niveau du service worker qui permet de stocker les ressources fournies par les réponses, et indexées par leurs requêtes. Cette API fonctionne d'une manière similaire au cache standard du navigateur, mais le cache demeure spécifique au domaine. Il persiste jusqu'à ce qu'il en soit décidé autrement — de nouveau, le contrôle reste total.</p> <div class="note"> -<p><strong>Remarque </strong>: L'API Cache n'est pas supportée par tous les navigateurs. (Voir la section {{anch("Compatibilité des navigateurs")}} pour plus d'informations.) Pour l'utiliser à l'heure actuelle, on peut envisager un polyfill comme celui fournit par la <a href="https://github.com/Polymer/topeka/blob/master/sw.js">démo Topeka de Google</a>, ou peut-être stocker les ressources dans <a href="/en-US/docs/Web/API/IndexedDB_API">IndexedDB</a>.</p> +<p><strong>Note :</strong> L'API Cache n'est pas supportée par tous les navigateurs. (Voir la section {{anch("Compatibilité des navigateurs")}} pour plus d'informations.) Pour l'utiliser à l'heure actuelle, on peut envisager un polyfill comme celui fournit par la <a href="https://github.com/Polymer/topeka/blob/master/sw.js">démo Topeka de Google</a>, ou peut-être stocker les ressources dans <a href="/en-US/docs/Web/API/IndexedDB_API">IndexedDB</a>.</p> </div> <p>Commençons cette section par l'examen d'un exemple de code — c'est le <a href="https://github.com/mdn/sw-test/blob/gh-pages/sw.js#L1-L18">premier bloc présent dans le service worker</a>:</p> -<pre class="brush: js notranslate">this.addEventListener('install', function(event) { +<pre class="brush: js">this.addEventListener('install', function(event) { event.waitUntil( caches.open('v1').then(function(cache) { return cache.addAll([ @@ -244,11 +241,11 @@ imgLoad('myLittleVader.jpg').then(function(response) { </ol> <div class="note"> -<p><strong>Remarque </strong>: <a href="/fr/docs/Web/API/Web_Storage_API">localStorage</a> fonctionne de la même façon que le cache du service worker, mais de manière synchrone, et il n'est donc pas autorisé dans les service workers.</p> +<p><strong>Note :</strong> <a href="/fr/docs/Web/API/Web_Storage_API">localStorage</a> fonctionne de la même façon que le cache du service worker, mais de manière synchrone, et il n'est donc pas autorisé dans les service workers.</p> </div> <div class="note"> -<p><strong>Remarque </strong>: <a href="/fr/docs/Web/API/API_IndexedDB">IndexedDB</a> peut être utilisé dans un service worker pour le stockage des donnés si nécessaire.</p> +<p><strong>Note :</strong> <a href="/fr/docs/Web/API/API_IndexedDB">IndexedDB</a> peut être utilisé dans un service worker pour le stockage des donnés si nécessaire.</p> </div> <h3 id="Réponses_personnalisées_aux_requêtes">Réponses personnalisées aux requêtes</h3> @@ -259,7 +256,7 @@ imgLoad('myLittleVader.jpg').then(function(response) { <p>On peut attacher un écouteur de l'événement <code>fetch</code> au service worker, puis appeler la méthode <code>respondWith()</code> sur l'événement pour détourner les réponses HTTP et les mettre à jour en leur jetant un sort particulier.</p> -<pre class="brush: js notranslate">this.addEventListener('fetch', function(event) { +<pre class="brush: js">this.addEventListener('fetch', function(event) { event.respondWith( // la magie opère ici ); @@ -267,7 +264,7 @@ imgLoad('myLittleVader.jpg').then(function(response) { <p>On peut déjà simplement répondre avec la ressource en cache dont l'url correspond à celle de la requête réseau, dans chaque cas :</p> -<pre class="brush: js notranslate">this.addEventListener('fetch', function(event) { +<pre class="brush: js">this.addEventListener('fetch', function(event) { event.respondWith( caches.match(event.request) ); @@ -281,29 +278,29 @@ imgLoad('myLittleVader.jpg').then(function(response) { <li> <p>Le constructeur <code>{{domxref("Response.Response","Response()")}}</code> permet de créer une réponse personnalisée. Dans cet exemple, une chaîne de caractères est simplement retournée :</p> - <pre class="brush: js notranslate">new Response('Hello from your friendly neighbourhood service worker!');</pre> + <pre class="brush: js">new Response('Hello from your friendly neighbourhood service worker!');</pre> </li> <li> <p>La <code>Response</code> plus complexe ci-dessous montre qu'il est possible de passer optionnellement un ensemble d'en-têtes avec la réponse, émulant ainsi des en-têtes de réponse HTTP standards. Ici, on signale au navigateur quel est le type de contenu de notre réponse artificielle :</p> - <pre class="brush: js notranslate">new Response('<p>Hello from your friendly neighbourhood service worker!</p>', { + <pre class="brush: js">new Response('<p>Hello from your friendly neighbourhood service worker!</p>', { headers: { 'Content-Type': 'text/html' } })</pre> </li> <li> <p>Si une correspondance n'est pas trouvée en cache, on peut indiquer simplement au navigateur d'effectuer ({{domxref("GlobalFetch.fetch","fetch")}}) la requête réseau par défaut pour cette ressource, afin de récupérer cette nouvelle ressource sur le réseau si disponible :</p> - <pre class="brush: js notranslate">fetch(event.request)</pre> + <pre class="brush: js">fetch(event.request)</pre> </li> <li> <p>Si une correspondance n'est pas trouvée en cache et que le réseau n'est pas disponible, on peut alors faire correspondre la requête avec une page de rechange par défaut en guise de réponse en utilisant {{domxref("CacheStorage.match","match()")}}, comme suit :</p> - <pre class="brush: js notranslate">caches.match('/fallback.html');</pre> + <pre class="brush: js">caches.match('/fallback.html');</pre> </li> <li> <p>On peut récupérer beaucoup d'informations à propos de chaque requête en interrogeant les paramètres de l'objet {{domxref("Request")}} retourné par {{domxref("FetchEvent")}} :</p> - <pre class="brush: js notranslate">event.request.url + <pre class="brush: js">event.request.url event.request.method event.request.headers event.request.body</pre> @@ -316,7 +313,7 @@ event.request.body</pre> <p>Heureusement, la structure des service workers qui repose sur les promesses rend triviale la gestion des alternatives à une situation de succès. On pourrait faire ceci :</p> -<pre class="brush: js notranslate">this.addEventListener('fetch', function(event) { +<pre class="brush: js">this.addEventListener('fetch', function(event) { event.respondWith( caches.match(event.request).catch(function() { return fetch(event.request); @@ -328,7 +325,7 @@ event.request.body</pre> <p>Plus malin encore, on pourrait non seulement récupérer la ressource à partir du serveur, mais aussi la sauvegarder dans le cache afin que les requêtes ultérieures pour cette ressource puissent être disponibles aussi en mode déconnecté. Cela signifierait que toute image supplémentaire ajoutée à la galerie Star Wars pourrait être récupérée par l'application et mise en cache. Le code suivant illustre ce mécanisme :</p> -<pre class="brush: js notranslate">this.addEventListener('fetch', function(event) { +<pre class="brush: js">this.addEventListener('fetch', function(event) { event.respondWith( caches.match(event.request).catch(function() { return fetch(event.request).then(function(response) { @@ -347,7 +344,7 @@ event.request.body</pre> <p>Le dernier problème qui demeure alors est l'échec de la requête au cas où elle n'a aucune correspondance dans le cache et que le réseau n'est pas disponible. Fournir un document de rechange par défaut permet quoiqu'il arrive, à l'utilisateur de récupérer quelque chose :</p> -<pre class="brush: js notranslate">this.addEventListener('fetch', function(event) { +<pre class="brush: js">this.addEventListener('fetch', function(event) { event.respondWith( caches.match(event.request).catch(function() { return fetch(event.request).then(function(response) { @@ -368,7 +365,7 @@ event.request.body</pre> <p>Ce code utilise un chaînage de promesses plus standard et retourne la réponse au document sans avoir à attendre que <code>caches.open()</code> soit résolue :</p> -<pre class="brush: js notranslate">this.addEventListener('fetch', function(event) { +<pre class="brush: js">this.addEventListener('fetch', function(event) { var response; event.respondWith(caches.match(event.request).catch(function() { return fetch(event.request); @@ -383,13 +380,13 @@ event.request.body</pre> })); });</pre> -<h2 id="Mettre_à_jour_le_service_worker"><a id="Updating your service worker" name="Updating your service worker">Mettre à jour le service worker</a></h2> +<h2 id="Mettre_à_jour_le_service_worker">Mettre à jour le service worker</h2> <p>Si le service worker a été précédemment installé, et qu'une nouvelle version du worker est disponible au chargement ou au rafraîchissement de la page, la nouvelle version est installée en arrière-plan, mais pas encore activée. Elle ne sera activée que lorsqu'il n'y aura plus aucune page chargée qui utilise encore l'ancien service worker. Dès lors qu'il n'y a plus de telles pages encore chargées, le nouveau service worker est activé.</p> <p>On souhaite mettre à jour l'écouteur d'événement <code>install</code> dans le nouveau service worker de la façon suivante (à noter le nouveau numéro de version) :</p> -<pre class="brush: js notranslate">this.addEventListener('install', function(event) { +<pre class="brush: js">this.addEventListener('install', function(event) { event.waitUntil( caches.open('v2').then(function(cache) { return cache.addAll([ @@ -417,7 +414,7 @@ event.request.body</pre> <p>Les promesses passées à <code>waitUntil()</code> bloqueront les autres événements jusqu'à réalisation complète, ainsi on a l'assurance que l'opération de nettoyage aura été menée à terme au moment où surviendra le premier événement <code>fetch</code> du nouveau cache.</p> -<pre class="brush: js notranslate">this.addEventListener('activate', function(event) { +<pre class="brush: js">this.addEventListener('activate', function(event) { var cacheWhitelist = ['v2']; event.waitUntil( @@ -438,7 +435,7 @@ event.request.body</pre> <p>Firefox a aussi commencé à implanter quelques outils utiles concernant les service workers :</p> <ul> - <li>Consulter <a>about:serviceworkers</a> pour voir quels SWs sont enregistrés et les mettre à jour ou les supprimer.</li> + <li>Consulter about:serviceworkers pour voir quels SWs sont enregistrés et les mettre à jour ou les supprimer.</li> <li>Lors de tests, il est possible de contourner la restriction HTTPS en cochant l'option "Activer les Service Workers via HTTP (lorsque la boîte à outils est ouverte)" dans les options des outils de développement de Firefox (la roue dentée dans le menu.)</li> </ul> |