Partager via

Prise en main du développement d’une PWA

Une application web progressive (PWA) est une application que vous créez à l’aide de technologies web telles que HTML, CSS et JavaScript, et qui peut également être installée et exécutée sur différents systèmes d’exploitation d’appareil, à partir d’un code base unique.

En utilisant cet article avec l’exemple de convertisseur de température, qui est fait pour apprendre à créer une PWA, vous serez en mesure de :

  • Personnalisez le convertisseur de température PWA en apportant des modifications mineures au code de l’exemple.

  • Créez votre propre PWA en copiant et collant l’intégralité de l’exemple de répertoire et en modifiant largement le code.

Voir aussi :

Architecture d’une application web progressive

Le diagramme suivant montre l’architecture générale d’une application web progressive (PWA) :

Diagramme d’architecture d’une PWA

Sur la gauche, l’appareil qui exécute le front-end de la PWA a les fichiers pour le code frontal d’une PWA.

Sur la droite, le serveur web exécute le code principal (ou le contenu de base de données) d’une PWA.

L’appareil contient le code frontal, notamment HTML, CSS, JavaScript, le worker de service et le manifeste. Cela est vrai, que l’application web progressive (PWA) soit utilisée en tant qu’application web dans le navigateur ou en tant qu’application locale installée sur l’appareil.

Comme une application web standard, une application web progressive est écrite à l’aide des langages de programmation du web : HTML, CSS et JavaScript, et est distribuée à vos utilisateurs à l’aide d’un serveur web. Si l’application web est une application web progressive, l’utilisateur voit initialement l’application web dans un navigateur web, et la barre d’adresses a également un bouton Application disponible qui invite l’utilisateur à installer l’application localement.

Déploiement d’une PWA sur un serveur web de production

Pour mettre une application web progressive (PWA) à la disposition des utilisateurs, vous déployez l’application web progressive (PWA) sur un serveur web accessible via HTTPS (contrairement à un environnement de développement local). Le serveur web envoie le code frontal aux utilisateurs et exécute le code principal pour l’application web.

Certaines parties de la plateforme progressive Web Apps (PWA), telles que les travailleurs du service, nécessitent l’utilisation de HTTPS.

Si l’application web progressive (PWA) n’a pas de code back-end, l’application web progressive (PWA) peut être servie à partir d’un serveur web statique. Par exemple, le convertisseur de température sur https://microsoftedge.github.io/Demos/temperature-converter/ utilise le serveur statique github.io de GitHub.

L’article Exemple de convertisseur de température vous permet d’exécuter et de tester l’exemple d’application web progressive sur votre serveur local. Lorsque votre propre application web progressive a été testée et est prête à être distribuée, vous distribuez la PWA testée à vos utilisateurs via un serveur web (un fournisseur d’hébergement web).

Pour mettre à jour votre application web progressive, vous déployez à nouveau la nouvelle version sur votre serveur web.

Exemples d’hôtes de serveur web

Lorsque votre application web progressive (PWA) est mise en ligne, vous devez la publier dans une URL HTTPS. De nombreux hôtes utilisent HTTPS par défaut, mais si votre hôte n’offre pas https, Let’s Encrypt offre une alternative gratuite pour créer les certificats nécessaires.

Par exemple, vous pouvez créer un compte Azure gratuit. Si vous hébergez votre site web sur microsoft Azure App Service, il est fourni via HTTPS par défaut.

Vous pouvez également héberger votre site web sur GitHub Pages (pages.github.com), qui prend en charge HTTPS. Consultez GitHub Pages documentation.

À propos de localhost (http) et du serveur de production (https)

Lorsque vous utilisez un serveur web de développement local à l’adresse localhost , l’URL commence généralement par http, et non httpspar . Les parties clés de la plateforme Progressive Web Apps, telles que les workers de service, nécessitent l’utilisation de HTTPS, et non de HTTP.

À des fins de développement et de débogage, Microsoft Edge (ou une fenêtre hébergeant une application locale PWA) autorise l’adresse localhost à exécuter les API PWA (Progressive Web App) sans HTTPS.

Fichiers de code front-end (code d’interface utilisateur)

Une application web progressive (PWA) a des fichiers de code front-end qui sont envoyés par le serveur web au navigateur sur l’appareil local.

Le code frontal est les ressources nécessaires à l’installation de l’application sur l’appareil de l’utilisateur, telles que le code HTML, CSS et JavaScript.

Une application web progressive (PWA) inclut généralement les fichiers de code front-end suivants :

  • Un fichier HTML pour décrire le contenu de votre application, tel que le texte, les images, les champs de texte ou les boutons qui apparaissent dans l’interface utilisateur.

  • Un fichier CSS pour organiser le contenu HTML dans une disposition et fournir des styles aux éléments.

  • Un fichier JavaScript pour ajouter des interactions utilisateur à votre interface utilisateur.

  • Un fichier manifeste JSON pour décrire votre application au système d’exploitation hôte.

  • Un fichier worker de service JavaScript pour mettre en cache les fichiers de code front-end de l’application et exécuter des tâches en arrière-plan.

Le code frontal d’une application web progressive (PWA) s’exécute à l’aide du navigateur web de l’appareil. L’interface utilisateur du navigateur n’est pas visible lorsque l’application est exécutée dans une fenêtre autonome, qui est une fenêtre de navigateur rationalisée avec des contrôles d’interface utilisateur de navigateur minimaux.

Code, fichiers, points de terminaison et données principaux (code côté serveur)

Une application web progressive (PWA) a potentiellement du code principal qui réside et s’exécute sur le serveur web.

Comme une application web, une application web progressive peut inclure du code principal (code côté serveur) qui implémente tous les points de terminaison d’API de service web nécessaires à votre application, lorsqu’elle est connectée à Internet, pour récupérer du contenu dynamique qui peut être stocké dans une base de données sur votre serveur.

Le code principal d’une application web progressive peut utiliser les langages côté serveur de votre choix, tels que :

  • ASP.NET
  • Java
  • Node.js
  • PHP

Les points de terminaison d’API de service web côté serveur peuvent ne pas être nécessaires, en fonction de l’application que vous créez.

L’exemple de convertisseur de température PWA n’a pas de code côté serveur, car l’application s’exécute exclusivement sur l’appareil sur lequel elle est installée et n’a pas besoin de données côté serveur.

Les sections restantes expliquent les fichiers qui composent l’exemple PWA.

Manifeste de l’application web (manifest.json)

Une application web standard s’exécute uniquement dans le navigateur. En ajoutant un manifeste d’application web, l’application web devient une application web progressive (PWA). Le manifeste d’application web permet aux navigateurs qui prennent en charge les PWA d’installer l’application web en tant qu’application web progressive sur l’appareil.

Un manifeste d’application web est un fichier JSON contenant des métadonnées sur l’application web progressive, telles que son nom, sa description, ses icônes et les différentes fonctionnalités du système d’exploitation qu’elle utilise. Le code JSON décrit l’application sur le système d’exploitation hôte. Le fichier manifeste fournit des informations de base sur l’application web progressive, que le système d’exploitation de l’appareil doit utiliser.

Le nom manifest.json de fichier est une convention courante, et non une exigence stricte.

Exemple manifest.json:

{
  "lang": "en-us",
  "name": "Temperature converter app",
  "short_name": "Temperature converter",
  "description": "A basic temperature converter application that can convert to and from Celsius, Kelvin, and Fahrenheit",
  "start_url": "./",
  "background_color": "#2f3d58",
  "theme_color": "#2f3d58",
  "orientation": "any",
  "display": "standalone",
  "icons": [
      {
          "src": "./icon512.png",
          "sizes": "512x512"
      }
  ]
}

Voir aussi :

Le service Worker pour mettre en cache les fichiers de l’application sur l’appareil local (sw.js)

Une application web progressive (PWA) peut utiliser un fichier JavaScript de travail de service (tel que sw.js), pour mettre en cache des fichiers d’interface utilisateur frontaux sur l’appareil local. Un worker de service est défini dans un fichier JavaScript dédié chargé par l’application (distinct du fichier principal .js contenant la logique de l’application).

Un worker de service est un worker web spécialisé qui peut intercepter les demandes réseau à partir de votre application web progressive. Le service Worker permet des scénarios tels que :

  • Prise en charge hors connexion, y compris la connexion intermittente à Internet.
  • Mise en cache avancée sur l’appareil.
  • Exécution de tâches en arrière-plan telles que la réception de messages PUSH, l’ajout de badges à l’icône d’application ou la récupération de données à partir d’un serveur.

Un worker de service est une technologie clé qui permet de rendre une application web progressive rapide et indépendante des conditions réseau. Le service Worker effectue l’application :

  • Plus rapide.
  • Plus fiable.
  • Indépendant du réseau ; l’application continue de fonctionner (d’une certaine manière), même avec une connexion Internet manquante ou intermittente.

Cet exemple de fichiersw.js est un worker de service qui gère la mise en cache des fichiers qui font partie du convertisseur de température PWA, en mettant en cache les fichiers sur le lecteur local et en les mettant en service lorsqu’il n’y a pas de connexion Internet.

sw.js:

const CACHE_NAME = `temperature-converter-v1`;
    
// Use the install event to pre-cache all initial resources.
self.addEventListener('install', event => {
  event.waitUntil((async () => {
    const cache = await caches.open(CACHE_NAME);
    cache.addAll([
      './',
      './converter.js',
      './converter.css'
    ]);
  })());
});

self.addEventListener('fetch', event => {
  event.respondWith((async () => {
    const cache = await caches.open(CACHE_NAME);

    // Get the resource from the cache.
    const cachedResponse = await cache.match(event.request);
    if (cachedResponse) {
      return cachedResponse;
    } else {
        try {
          // If the resource was not in the cache, try the network.
          const fetchResponse = await fetch(event.request);
    
          // Save the resource in the cache and return it.
          cache.put(event.request, fetchResponse.clone());
          return fetchResponse;
        } catch (e) {
          // The network failed
        }
    }
  })());
});

Ce service Worker met explicitement en cache trois fichiers :

  • ./ moyens index.html
  • ./converter.js
  • ./converter.css

Deux fichiers supplémentaires sont mis en cache automatiquement par le navigateur :

  • Fichier d’icône (.png).
  • Fichier manifeste (.json).

Écoute de l’événement install

Le service Worker écoute l’événement install , qui est déclenché lorsque l’utilisateur installe l’application, et l’utilise pour mettre en cache les ressources dont votre application a besoin pour fonctionner hors connexion, par exemple :

  • Page HTML initiale.
  • Fichier JavaScript principal de l’application qui contient la logique de l’application.
  • Fichier CSS de l’application.

Pour activer l’installation de l’application, un fichier worker de service JavaScript permet à l’application de fonctionner hors connexion (sans toujours disposer d’une connexion Internet) en mettant en cache les fichiers front-end nécessaires sur l’appareil local.

Écoute de l’événement fetch

Le service Worker intercepte les fetch événements, qui se produisent chaque fois que votre application envoie une requête au serveur, et applique une stratégie de mise en cache d’abord.

Le service Worker retourne les ressources mises en cache pour que votre application puisse fonctionner hors connexion. En cas d’échec, le service Worker tente de télécharger le fichier à partir du serveur à la place.

Un worker de service est facultatif

Une application web progressive (PWA) n’a pas besoin d’un worker de service pour que Microsoft Edge puisse installer l’application. Toutefois, nous vous recommandons d’inclure un worker de service dans votre propre application web progressive pour la rendre plus rapide et pour rendre l’application plus fiable, par exemple lorsque votre appareil dispose d’une connexion réseau intermittente ou est hors connexion.

Voir aussi :

Étapes suivantes

Effectuez les étapes décrites dans Exemple de convertisseur de température. Ensuite, pour créer votre propre application web progressive (PWA), vous pouvez copier, coller et modifier le Demos\temperature-converter répertoire. L’exemple de convertisseur de température montre seulement un petit échantillon de ce que l’Web Apps progressif (PWA) peut faire. L’exemple illustre le code qui est important pour toute application web progressive (PWA), par exemple lorsqu’il n’y a pas de connexion Internet.

Il existe d’autres bonnes pratiques pour les PWA pour faire d’une application web progressive (PWA) une application native :

  • Intégrez l’application au système d’exploitation, par exemple en gérant des fichiers.

  • Effectuer des tâches de calcul non dérivées.

  • Chargez l’application dans les magasins d’applications.

Voir également

MDN :

Hébergement:

Échantillon:

  • Last updated on