web-dev-qa-db-fra.com

Cache d'application ou travailleurs de service - lequel utiliser en 2016 / T2?

Question rapide pour discussion vraiment, car je voulais avoir la contribution de différentes personnes.

Je suis en train de développer une application de page Web qui doit être disponible hors ligne.

Maintenant, pour ce faire, si je comprends bien, vous devez utiliser la fonctionnalité de mise en cache des applications ou utiliser des travailleurs de service.

Cependant, voici l'énigme que j'ai. Lors de la recherche du cache d'application, le MDN indique clairement :

Obsolète:
Cette fonctionnalité a été supprimée des normes Web. Bien que certains navigateurs puissent toujours le prendre en charge, il est en cours de suppression. Ne l'utilisez pas dans des projets anciens ou nouveaux. Les pages ou les applications Web qui l'utilisent peuvent se casser à tout moment.

Après quoi, une autre boîte de dialogue suggère d'utiliser à la place des travailleurs de service.

La page Service Workers indique ensuite comment les Service Workers sont une technologie expérimentale, et il est préférable de consulter le tableau de compatibilité.

Le tableau de compatibilité indique que Safari et Internet Explorer ne prennent pas en charge les Service Workers. Autres consultations ce site et en supposant qu'il est exact, il indique que Microsoft a commencé à intégrer les travailleurs des services, mais pour Safari, ils sont "à l'étude" avec "de brefs signaux positifs dans un plan quinquennal".

Maintenant, c'est une préoccupation pour le projet actuel car il est essentiel qu'il soit compatible safari, cependant, je ne veux pas non plus qu'il se casse dans d'autres navigateurs.

Quelles seraient vos recommandations? Allez simplement avec l'ancienne mise en cache des applications et mettez-la à jour dans un avenir proche? Déterminer le navigateur des utilisateurs et agir de manière appropriée? Ou, y a-t-il un autre moyen qui me manque?

26
Ben Davison

Il y a certainement la possibilité d'utiliser les deux en même temps. Si vous souhaitez déployer une application multi-navigateur au cours des deux prochaines années, j'ai l'impression que vous devez continuer à utiliser AppCache, car iOS ne "pense" qu'à l'implémentation de Service Workers dans les 5 prochaines années.

Voici du JavaScript que nous utilisons pour détecter s'il faut utiliser l'un ou l'autre et pour initialiser les deux

if ( 'serviceWorker' in navigator && b ) {
navigator.serviceWorker.register('/sw.js').then(function(registration) {
// Registration was successful
showMsg('ServiceWorker registration successful with scope: ', registration.scope);
if ( registration.installing ) {
  showMsg( 'Service worker installing' );
} else if ( registration.waiting ) {
  showMsg( 'Service worker installed' );
} else if ( registration.active ) {
  showMsg( 'Service worker active' );
}
  }).catch(function(err) {
    // registration failed :(
    showMsg('ServiceWorker registration failed: ', err);
  });

// Listen for claiming our ServiceWorker
navigator.serviceWorker.addEventListener('controllerchange', 
function(event) {
      // Listen for changes in the state of our ServiceWorker
      navigator.serviceWorker.controller.addEventListener('statechange', function() {
        // If the ServiceWorker becomes "activated", let the user know they can go offline!
        if (this.state === 'activated') {
        // This example is refreshing the app directly, but you can inform the user with a fancy modal window or similar
            window.location.reload( true );
        }
      });
    });

// Browsers not using Service Workers
    } else  if ('applicationCache' in window) {
      var iframe = document.createElement('iframe');
      iframe.style.display = 'none';
      iframe.src = 'load-appcache.html'
      document.body.appendChild(iframe);
      showMsg("Iframe loaded for AppCache management");

    } else {
      showMsg("no service worker - no appCache");

 }

Le code décrit pour initialiser AppCache permet d'actualiser les nouvelles pages lorsque le fichier appcache change. Je l'ai récupéré auprès de plusieurs sources mais toutes issues de la puissante présentation que Patrick Kettner a prononcée lors du PWA Dev Summit 2016: ( https://www.youtube.com/watch?v=IgckqIjvR9U&t=1005s )

load-appcache.html ne contient que

<!DOCTYPE html>
<html manifest="offline.appcache">
    <head>
        <title>loding appCache</title>
   </head>
   <body></body>
</html>

Il y a bien sûr plusieurs possibilités que SW offre pour fournir une application plus sophistiquée, mais avec AppCache et IDB, vous pouvez en effet faire à peu près n'importe quelle logique métier que vous voulez, y compris des capacités hors ligne.

Attention, vous ne pourrez pas tester la fonctionnalité AppCache avec Chrome car ils l'ont désactivé, mais vous pouvez toujours forcer Firefox (j'ai testé avec 50.1.0). Vous pouvez toujours utiliser Safari cependant :)

10
Miguel Guardo

Vous pouvez choisir d'utiliser Service Workers et AppCache sur la même application Web. Dans un tel cas, les navigateurs qui ne prennent pas en charge les Service Workers utiliseront AppCache, et ceux qui le feront ignoreront AppCache et laisseront le Service Worker prendre le relais.

Sources: https://www.w3.org/TR/service-workers/#activation-algorithm , https://crbug.com/410665

10
Daniel Herr

Vous avez raison, appcache ne prend plus en charge .

Et il existe d'autres options qui stockent des données et/ou des actifs dans IDB, telles que:

Essayez de googler " braise hors ligne pouchdb " ou " hors poche pouchdb angulaire " pour plus d'exemples.

Les seuls mécanismes pour garantir la disponibilité hors ligne en ce moment sont les travailleurs de service et appcache. Période.

Toutes ces techniques reposent sur le fait que votre site est une application d'une seule page et que le point d'entrée doit être accessible. Donc, si vous n'utilisez pas Appcache ou des travailleurs de service pour vous assurer que le point d'entrée est toujours accessible, vous devez revenir au cache http et définir correctement en-têtes liés au cache lorsque vous servez vos actifs. Quoi qu'il en soit, le cache http peut être expulsé à tout moment par l'UA.

Face à cette décision, si il est obligatoire que l'application s'exécute hors ligne et dans Safari , la seule option est d'utiliser appcache (AFAIK, il n'y a pas de news pour supprimer appcache de Safari).

Pour réduire le risque, vous pouvez opter pour la combinaison de l'une des techniques précédentes (celles qui stockent les actifs sur IndexedDB) en plus d'Appcache, de sorte que la seule chose que vous mettez en cache est le point d'entrée pour le SPA. Si appcache n'est plus pris en charge et qu'il n'y a pas d'alternative de service worker, vous pouvez passer à l'alternative d'en-têtes de cache.

Quoi qu'il en soit, vous pouvez utiliser la détection des fonctionnalités (if ('serviceWorker' in navigator) { ... }) pour voir si les techniciens de maintenance sont disponibles et l'utiliser au cas où cela l'est. Il existe un polyfill pour appcache basé sur les travailleurs de service appelé JakeCache (non testé) et d'autres sont à venir .

9
Salva

Selon le document HTML5 Work Workers Doc de Mozilla:

Remarque: Une grande chose au sujet des travailleurs de service est que si vous utilisez la détection de fonctionnalités comme nous l'avons montré ci-dessus, les navigateurs qui ne prennent pas en charge les travailleurs de service peuvent simplement utilisez votre application en ligne de la manière normale attendue. En outre, si vous utilisez AppCache et SW sur une page, les navigateurs qui ne prennent pas en charge SW mais prennent en charge AppCache l'utiliseront, et les navigateurs qui prennent en charge les deux ignoreront AppCache et laisseront SW prendre le relais.

Code "ci-dessus":

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);
  }).catch(function(error) {
    // registration failed
    console.log('Registration failed with ' + error);
  });
}

https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API/Using_Service_Workers

2
Jersh