diff --git a/files/fr/web/progressive_web_apps/tutorials/js13kgames/app_structure/index.md b/files/fr/web/progressive_web_apps/tutorials/js13kgames/app_structure/index.md index f9d44dd88f28ea..671a07b130d1f7 100644 --- a/files/fr/web/progressive_web_apps/tutorials/js13kgames/app_structure/index.md +++ b/files/fr/web/progressive_web_apps/tutorials/js13kgames/app_structure/index.md @@ -1,66 +1,23 @@ --- -title: Structure d'une Progressive web app +title: Structure d'une application web progressive slug: Web/Progressive_web_apps/Tutorials/js13kGames/App_structure +l10n: + sourceCommit: acfe8c9f1f4145f77653a2bc64a9744b001358dc --- -{{PreviousMenuNext("Web/Apps/Progressive/Introduction", "Web/Apps/Progressive/Offline_Service_workers", "Web/Apps/Progressive")}} +{{PreviousMenuNext("Web/Progressive_web_apps/Tutorials/js13kGames", "Web/Progressive_web_apps/Tutorials/js13kGames/Offline_Service_workers", "Web/Progressive_web_apps/Tutorials/js13kGames")}} -Maintenant que nous avons pris connaissances des principes théoriques sur lesquelles sont bâties les PWAs, penchons nous sur la structure recommandée d'une vraie application. Nous commencerons par analyser l'application [js13kPWA](https://mdn.github.io/pwa-examples/js13kpwa/) et par examiner pourquoi elle est construite de cette façon et quels bénéfices elle en retire. +{{PWASidebar}} -## Architecture d'une application +Dans cet article, nous analyserons l'application [js13kPWA](https://mdn.github.io/pwa-examples/js13kpwa/), verrons pourquoi elle est construite de cette façon et les avantages que cela apporte. -Il existe deux approches majeures distinctes pour générer un site web - côté serveur ou côté client. Les deux approches ont leurs avantages et leurs inconvénients et vous pouvez panacher jusqu'à un certain point les deux approches. +La structure du site web [js13kPWA](https://mdn.github.io/pwa-examples/js13kpwa/) est plutôt simple : elle consiste en un simple fichier HTML ([`index.html`](https://github.com/mdn/pwa-examples/blob/master/js13kpwa/index.html)) avec un style CSS basique ([`style.css`](https://github.com/mdn/pwa-examples/blob/master/js13kpwa/style.css)) et quelques images, scripts et polices de caractères. La structure du répertoire ressemble à ceci : -- La génération côté serveur (Server-side rendering ou SSR) signifie qu'un site web est généré sur le serveur, si bien qu'il bénéficie d'un temps de chargement initial plus court mais la navigation d'une page à l'autre impose de télécharger à chaque foois un nouveau contenu HTML. Cela fonctionne parfaitement pour les navigateurs mais au prix d'un temps de navigation accru pour passer d'une page à l'autre, et donc diminue la performance générale perçue - charger une page nécessite un nouvel allerr-retour avec le serveur. -- La génération côté client (Client-side rendering ou CSR) permet au site web d'être mis à jour presque instantanément en navigant sur des pages différentes mais nécessite au début un téléchargement intial plus important et un travail de rendu supplémentaires côté client. Le site web est plus lent lors d'une première visite mais peut être plus rapide ensuite quand on y navigue. - -Mélanger SSR et CSR peut permettre d'obtenir de meilleurs résultats - vous pouvez générer un site web côté serveur, mettre en cache son contenu puis mettre à jour le rendu côté client si et quand c'est nécessaire. Le chargement de la première page est rapide grâce au SSR et la navigation entre les pages est fluide car le client peut regénérer la page en ne modifiant que les parties qui ont changé. - -Les PWAs peuvent être construite en utilisant l'approche que vous préférez, mais certaines fonctionneront mieux que les autres. L'approche la plus populaire est celle utilisant le concept d' "app shell"; qui mélange SSR et CSR exactement comme cela a été décrit plus haut et se conforme de surcroit à la méthodologie "déconnectée d'abord" ("offline first") que nous expliquerons en détails dans de prochains articles et que nous utiliserons dans notre application exemple. Il existe également une nouvelle approche utilisant l'[API Streams](/fr/docs/Web/API/Streams_API) et dont nous parlerons brièvement. - -## App shell - -Le concept d'App shell s'occupe de charger une interface utilisateur minimale dès que possible puis de la mettre en cache de façon à ce qu'elle soit disponible en mode déconnecté lors des visites suivantes, avant de charger tout le contenu de l'application. De cette façon, la prochaine fois que quelqu'un visite l'application avec un appareil, l'interface utilisateur est chargée immédiatement depuis le cache puis les nouveaux contenus sont demandés au serveur (s'ils ne sont pas déjà disponibles dans le cache). - -Cette structure est rapide et est également ressentie comme telle par l'utilisateur car il voit "quelque chose" instantanément, plutôt qu'un indicateur de chargement en train de tourner ou une page blanche. Cela permet également au site web d'être accessible en mode déconnecté si une connexion réseau n'est pas disponible. - -Nous pouvons contrôler ce qui est demandé au serveur et ce qui est récupéré dans le cache grâce à un [service worker](/fr/docs/Web/API/Service_Worker_API) qui sera expliqué en détail dans le prochain article - pour le moment, concentrons-nous sur la structure en elle-même. - -### Pourquoi dois-je l'utiliser ? - -Cette architecture permet à un site web de bénéficier de la plupart des fonctionnalités PWA - elle met en cache l'app shell et gère le contenu dynamique d'une manière qui améliore grandement les performances. En plus de la structure de base, vous pouvez ajouter d'autres fonctionnalités telles que [l'ajouter à l'écran d'accueil](/fr/docs/Web/Apps/Progressive/Add_to_home_screen) ou [l'envoi de notifications](/fr/docs/Web/API/Push_API), sachant que l'application fonctionnera toujours correctement si elles ne sont pas prises en charge par le navigateur de l'utilisateur - c'est la beauté de l'amélioration continue. - -Le site web se comporte comme une application native, offrant une interaction instantannée et de solides performances tout en conservant les avantages du web. - -### Être accessible par un lien, progressive et de conception adaptative - -Il est important de se rappeler les avantages des PWA et de les garder à l'esprit lorsqu'on conçoit l'application. L'approche app shell permet aux sites web d'être : - -- Accessible par un lien: Même s'il se comporte comme une application native, il reste un site web - vous pouvez cliquer sur les liens d'une page et envoyer une URL à quelqu'un si vous voulez le partager. -- Progressive: Commencer avec un "bon vieux site web basic" et ajouter progressivement de nouvelles fonctionnalités tout en se rappelant de détecter si elles sont disponibles dans le navigateur et de gérer proprement toute erreur qui pourrait survenir si la prise en charge n'est pas disponible. Par exemple, un mode déconnecté possible grâce aux service workers n'est qu'une caractéristique bonus qui améliore l'expérience sur le site web, mais ce dernier reste totalement fonctionnel sans elle. -- Adaptatif: La conception web adaptative s'applique également aux applications web progressives, attendu que les deux sont principalement destinés aux appareils mobiles. Il y a tellements d'appareils différents en plus des navigateurs - il est important de préparer votre site web à fonctionner sur différentes tailles d'écran, supports d'affichage ou densité de pixels, en utilisant des technologies telles que [les tags meta viewport](/fr/docs/Mozilla/Mobile/Viewport_meta_tag), [les reqêtes media CSS](/fr/docs/Web/CSS/Media_Queries/Using_media_queries), [les Flexbox](/fr/docs/Web/CSS/CSS_Flexible_Box_Layout) et les [Grid CSS](/fr/docs/Web/CSS/CSS_Grid_Layout). - -## Approche différente : les streams - -Une approche totalement différente du rendu côté serveur - ou client - peut être obtenue à l'aide de l'[API Streams](/fr/docs/Web/API/Streams_API). Avec un peu d'aide des service workers, les streams peuvent grandement améliorer la façon dont nous analysons le contenu. - -Le modèle app shell nécessite que toutes les ressources soient disponibles avant que le site puisse commencer à être rendu. C'est différent avec HTML pour lequel le navigateur diffuse immédiatement les données si bien que vous pouvez voir quand les éléments sont chargés et et rendus sur le site web. Pour que le JavaScript soit "opérationnel", cependant, il faut attendre qu'il ait été entièrement téléchargé au préalable. - -L'API Streams permet aux développeurs d'avoir un accès direct au flux de données provenant du serveur - si vous voulez exécuter une opération sur les données (par exemple ajouter un filtre à une vidéo), vous n'avez plus besoin d'attendre que tout soit téléchargé et converti en un blob (ou autre) - vous pouvez commencer immédiatement. Cela permet un contrôle fin - le flux peut être démarré, chaîné avec un autre flux, annulé, ses erreurs contrôlées, et plus. - -En théorie, le flux est un meilleur modèle, mais il est également plus complexe et au moment de la rédaction (mars 2018), l'API Stream est toujours un travail en cours et pas encore totalement disponible pour l'ensemble des navigateurs principaux. Quand elle sera disponible, elle sera le moyen le plus rapide de servir le contenu - les bénéfices sont sur le point d'être énormes en terme de performance. - -Pour voir des exemples fonctionnels et disposer de davantage d'information, voir [la documention de l'API Streams](/fr/docs/Web/API/Streams_API). - -## Structure de notre application exemple - -La structure du site web [js13kPWA](https://mdn.github.io/pwa-examples/js13kpwa/) est plutôt simple: elle consiste en un simple fichier HTML ([index.html](https://github.com/mdn/pwa-examples/blob/master/js13kpwa/index.html)) avec un style CSS basique ([style.css](https://github.com/mdn/pwa-examples/blob/master/js13kpwa/style.css)) et quelques images, scripts et polices de caractères. La structure du répertoire ressemble à ceci: - -![Folder structure of js13kPWA.](js13kpwa-directory.png) +![Structure des dossiers de js13kPWA.](js13kpwa-directory.png) ### Le HTML -Du point de vue HTML, l'app shell est tout ce qui est à l'extérieur de la section content: +Du point de vue HTML, le squelette de l'application est formé par tout ce qui se trouve en dehors de l'élément [`
`](/fr/docs/Web/HTML/Element/section) : ```html @@ -74,8 +31,10 @@ Du point de vue HTML, l'app shell est tout ce qui est à l'extérieur de la sect - - + + @@ -84,17 +43,17 @@ Du point de vue HTML, l'app shell est tout ce qui est à l'extérieur de la sect

- +

js13kGames A-Frame entries

List of games submitted to the - A-Frame category in the - js13kGames 2017 competition. + A-Frame category in the + js13kGames 2017 competition. You can fork js13kPWA on GitHub -

// Le contenu est inséré ici
+
// Content inserted in here
``` -La section {{htmlelement("head")}} contient certaines informations de base telles que le titre, la description et des liens vers les CSS, le manifeste web, le fichier JS contenant les jeux et app.js — c'est là où notre application JavaScript est initialisée. Le {{htmlelement("body")}} est divisé en {{htmlelement("header")}} (contenant les images liées), {{htmlelement("main")}} la page (avec le titre, la description et un emplacement pour le contenu) et {{htmlelement("footer")}} (le copyright et les liens). +La section [``](/fr/docs/Web/HTML/Element/head) contient certaines informations de base telles que le titre, la description et des liens vers les CSS, le manifeste web, le fichier JS contenant les jeux et `app.js`, là où notre application JavaScript est initialisée. Le [corps (``)](/fr/docs/Web/HTML/Element/body) est divisé en trois avec [`
`](/fr/docs/Web/HTML/Element/header) (contenant les images liées), [`
`](/fr/docs/Web/HTML/Element/main) la page (avec le titre, la description et un emplacement pour le contenu) et [`