Application Shell UX avec streaming et service workers

Obtenez une architecture de type SPA dans des applications multipages en combinant des partiels, des service Workers et des flux.

23 juin 2020
Mise à jour 20 août 2020

Il apparaît dans:
Fiabilité du réseau

Demande d'une seule page (SPA) est un modèle architectural dans lequel le navigateur exécute du code JavaScript pour actualiser la page existante lorsque l'utilisateur visite une section différente du site, plutôt que de charger une nouvelle page entière.

Cela signifie que l'application Web n'effectue pas de véritable rechargement de page. Les API historique il est utilisé à la place pour naviguer d'avant en arrière dans l'historique de l'utilisateur et manipuler le contenu de la pile d'historique.

L'utilisation de ce type d'architecture peut fournir un Application shell UX c'est rapide, fiable et consomme généralement moins de données lors de la navigation.

Dans les applications multipages (MPA), chaque fois qu'un utilisateur accède à une nouvelle URL, le navigateur génère progressivement du HTML spécifique à cette page. Cela signifie une actualisation complète de la page chaque fois que vous visitez une nouvelle page.

Bien que les deux soient des modèles tout aussi valables à utiliser, vous souhaiterez peut-être apporter certains des avantages du shell d'application SPA UX à votre site MPA existant. Dans cet article, nous verrons comment obtenir une architecture de type SPA dans des applications multipages en combinant des partiels, des service Workers et des flux.

Cas de production

DÉVELOPPEUR est une communauté où les développeurs de logiciels écrivent des articles, participent à des discussions et créent leurs profils professionnels.

Son architecture est une application multipage basée sur des modèles backend traditionnels via Ruby on Rails. Son équipe était intéressée par certains des avantages d'un modèle de shell d'application, mais ne souhaitait pas entreprendre de changement architectural majeur ni s'éloigner de sa pile technologique d'origine.

Voici comment fonctionne votre solution :

1. Tout d'abord, ils créent des partiels de leur page d'accueil pour l'en-tête et le pied de page (shell_top.html y shell_bottom.html) et publiez-les sous forme de fragments HTML séparés avec un point. Ces actifs sont ajoutés au cache dans le service worker. installer événement (communément appelé mise en cache).
2. Lorsque le service worker intercepte une requête de navigation, il crée un réponse transmise combinant l'en-tête et le pied de page mis en cache avec le contenu de la page principale qui vient d'arriver du serveur. Le corps est la seule partie réelle de la page qui nécessite la récupération de données sur le réseau.

L'élément clé de cette solution est l'utilisation de courants, permettant créations et mises à jour incrémentielles de sources de données. L'API Streams fournit également une interface pour lire ou écrire des morceaux de données asynchrones, dont seul un sous-ensemble peut être disponible en mémoire à un moment donné. De cette façon, l'en-tête de la page peut être rendu dès qu'il est sélectionné dans le cache, tandis que le reste du contenu est récupéré du réseau. En conséquence, l’expérience de navigation est si rapide que les utilisateurs ne remarquent pas d’actualisation réelle de la page, seul le nouveau contenu (le corps) est mis à jour.

L’expérience utilisateur qui en résulte est similaire au modèle d’expérience utilisateur du shell d’application SPA, implémenté sur un site MPA.

Implémenter une architecture UX shell d'application dans MPA avec Workbox

Dans cette section, nous couvrirons un aperçu des différentes parties impliquées dans la mise en œuvre d'une architecture UX shell d'application dans MPA. Pour un article plus détaillé sur la façon de mettre en œuvre cela sur un site réel, voir Au-delà des SPA: architectures alternatives pour votre PWA.

Le serveur

Partiels

La première étape consiste à adopter une structure de site partiellement basée sur HTML. Ce ne sont que des éléments modulaires de vos pages qui peuvent être réutilisés sur votre site et peuvent également être livrés sous forme de fragments HTML autonomes.

Les tête partielle peut contenir toute la logique nécessaire pour styliser et afficher l'en-tête de la page. Les barre de navigation partielle peut contenir la logique de la barre de navigation, le pied de page partiel le code qui doit s'y exécuter, et ainsi de suite.

Lors de la première visite de l'utilisateur sur le site, votre serveur génère une réponse en assemblant les différentes parties de la page :

application . get ( routes . get ( 'index' ) , async ( req , res ) => {
 rés . écrire ( headPartial + navbarPartial ) ;
 balise const = req . requête . étiquette || DEFAULT_TAG ;
 const data = attendre requestData ( … ) ;
 rés . écrire ( modèles . index ( balise , données . éléments ) ) ;
 rés . écrire ( footPartial ) ;
 rés . fin ( ) ;
 } ) ;

En utilisant le bœuf (réponse) de l'objet méthode d'écritureet en faisant référence à des modèles partiels stockés localement, la réponse peut être transmis immédiatement, sans être bloqué par aucune source de données externe. Le navigateur prend ce HTML initial et affiche immédiatement une interface significative et un message de chargement.

La partie suivante de la page utilise des données API, ce qui implique une requête réseau. L'application Web ne peut rien traiter d'autre jusqu'à ce qu'elle reçoive une réponse et la traite, mais au moins les utilisateurs ne regardent pas un écran vide pendant qu'ils attendent.

Le travailleur des services

La première fois qu'un utilisateur visite un site, l'en-tête de la page s'affichera plus rapidement, sans avoir à attendre le corps de la page. Le navigateur doit encore accéder au réseau pour trouver le reste de la page.

Après le chargement de la première page, le service worker s'enregistre, lui permettant d'obtenir les partiels des différentes parties statiques de la page (en-tête, barre de navigation, pied de page, etc.) à partir du cache.

Mise en cache des actifs statiques

La première étape consiste à mettre en cache les modèles HTML partiels afin qu'ils soient disponibles immédiatement. Avec Boîte de travail préchargée Vous pouvez stocker ces fichiers dans le installer événement de service worker et tenez-les à jour lorsque des modifications sont mises en œuvre dans l'application Web.

En fonction du processus de build, Workbox propose différentes solutions pour générer un service worker et indiquer la liste des fichiers à précharger, notamment package web y gorgée accessoires, un module nodejs générique et un interface de ligne de commande.

Pour une configuration partielle comme celle décrite ci-dessus, le fichier de service worker résultant doit contenir quelque chose de similaire à ce qui suit :

boîte de travail . mise en cache . precacheAndRoute ( [
 {
 URL : 'partials/about.html' ,
 révision : '518747aad9d7e' ,
 } ,
 {
 URL : 'partials/foot.html' ,
 révision : '69bf746a9ecc6' ,
 } ,
 ] ) ;

Transmission

Ensuite, ajoutez une logique de service worker afin que le code HTML partiel mis en cache puisse être renvoyé immédiatement à l'application Web. C’est un élément crucial pour être rapide et fiable. En utilisant le API Streams au sein de notre travailleur de service, cela est possible.
Flux de boîtes de travail résume les détails du fonctionnement de la transmission. Le package vous permet de transmettre à la bibliothèque une combinaison de sources de streaming, à la fois des caches et des données d'exécution pouvant provenir du réseau. Workbox est chargé de coordonner les sources individuelles et de les unir en une seule réponse en streaming.

Tout d’abord, configurez des stratégies dans Workbox pour gérer les différentes sources qui constitueront la réponse en streaming.

const cacheStrategy = boîte de travail . stratégies . cachePremier ( {
 cacheName : boîte de travail . noyau . noms de cache . pré-cache ,
 } ) ;
 const apiStrategy = boîte de travail . stratégies . staleWhileRevalidate ( {
 Nom du cache : API_CACHE_NAME ,
 plugins : [
 nouvelle boîte de travail . expiration . Plugin ( { maxEntries : 50 } ) ,
 ] ,
 } ) ;

Ensuite, indiquez à Workbox comment utiliser les stratégies pour créer une réponse de streaming complète, en transmettant une série de sources sous forme de fonctions à exécuter immédiatement :

boîte de travail . flux . stratégie ( [
 ( ) => cacheStrategy . makeRequest ( { requête : '/head.html' } ) ,
 ( ) => cacheStrategy . makeRequest ( { requête : '/navbar.html' } ) ,
 async ( { événement , url } ) => {
 balise const = url . paramètres de recherche . obtenir ( 'balise' ) || DEFAULT_TAG ;
 const listResponse = attendre apiStrategy . makeRequest ( … ) ;
 const data = wait listResponse . json ( ) ;
 modèles de retour . index ( balise , données . éléments ) ;
 } ,
 ( ) => cacheStrategy . makeRequest ( { requête : '/foot.html' } ) ,
 ] ) ;

• Les deux premières sources sont des modèles partiels mis en cache, lus directement à partir du cache du service worker, ils seront donc toujours disponibles immédiatement.
• La fonction source suivante récupère les données du réseau et traite la réponse dans le code HTML attendu par l'application Web.
• Enfin, une copie en cache du pied de page et des balises HTML de fermeture sont transmises pour compléter la réponse.

Workbox prend le résultat de chaque source et le transmet à l'application Web, dans l'ordre, en retardant uniquement si la fonction suivante du tableau n'est pas encore terminée. En conséquence, l’utilisateur voit immédiatement la page en train d’être peinte. L'expérience est si rapide que lors de la navigation dans l'en-tête, il reste dans sa position sans que l'utilisateur ne remarque la mise à jour de toute la page. Ceci est très similaire à l’UX fourni par le modèle SPA du shell d’application.