- Certains présentent htmx comme s’il allait sauver le web des SPA
- Le créateur de htmx, Carson Gross, décrit avec humour cette dynamique comme une « dialectique hégélienne » :
- thèse : le MPA traditionnel
- antithèse : la SPA
- synthèse : une application composée d’îlots interactifs fondés sur l’hypermédia
- Mais je n’ai pas vu cela, et j’avais déjà « créé une SPA avec htmx » autrefois
- Il s’agit d’une preuve de concept pour une simple appli de liste de tâches
- une fois la page chargée, elle ne communique plus avec le serveur
- tout est traité localement côté client
- si htmx se concentre sur la gestion des échanges d’hypermédia via le réseau, comment cela peut-il fonctionner ?
- une astuce toute simple : le code « côté serveur » s’exécute dans un Service Worker
Service Worker
- Il agit comme un proxy entre la page web et Internet
- Il peut intercepter et manipuler les requêtes réseau
- Il peut modifier les requêtes, mettre en cache les réponses pour le mode hors ligne et générer de nouvelles réponses sans envoyer la requête hors du navigateur
- C’est cette dernière capacité qui est au cœur de cette application monopage
- Quand htmx émet une requête réseau, le Service Worker l’intercepte
- Ensuite, le Service Worker exécute la logique métier et génère un nouveau HTML
- htmx remplace alors le DOM avec ce nouveau HTML
Avantages par rapport à une SPA classique
- Le Service Worker doit utiliser IndexedDB comme stockage
- Cela permet de conserver l’état entre les chargements de page
- Même si l’on ferme la page puis qu’on revient, l’application se souvient des données
- C’est un avantage collatéral obtenu « gratuitement » en choisissant cette architecture
- Il est aussi facile de la faire fonctionner hors ligne
Inconvénients
- La prise en charge par les outils de développement est médiocre
console.log est parfois ignoré- les informations sur l’installation du Service Worker ne sont pas fiables
- Absence de prise en charge des modules ES dans Firefox
- tout le code doit tenir dans un seul fichier
- L’expérience de développement générale n’est « pas amusante »
Malgré tout, la SPA htmx fonctionne bien
Détails d’implémentation
- Le HTML de base est le squelette vide de l’application monopage
- La balise
<body> configure le cœur de l’application avec htmx
hx-boost="true" : indique à htmx de remplacer en Ajax les réponses aux clics sur les liens et aux soumissions de formulaires, sans navigation de page complètehx-push-url="false" : empêche htmx de modifier l’URL lors des clics sur les liens et des soumissions de formulaireshx-get="./ui" : indique de récupérer la page depuis /ui au chargement et de la remplacerhx-target="body" : indique de remplacer le résultat dans l’élément <body>hx-trigger="load" : indique d’exécuter tout cela au chargement de la page
Point de terminaison /ui
- Il renvoie le vrai balisage de l’application
- Ensuite, htmx prend le contrôle des liens et des formulaires pour la rendre interactive
- Le Service Worker gère le routage des requêtes avec une bibliothèque de style Express
setFilter et listTodos sont de simples fonctions qui encapsulent IDB Keyval- Le composant
App se compose d’un formulaire de filtre, d’une liste de tâches et d’un formulaire d’ajout
Point de terminaison /todos/add
- Il enregistre une tâche puis renvoie une réponse qui réaffiche l’UI
- htmx remplace la réponse dans le DOM
Composant Todo
- Il se compose d’une case à cocher, d’un bouton de suppression et du texte de la tâche
- La case à cocher déclenche une requête vers
/todos/${id}/update
- Le bouton de suppression déclenche une requête DELETE vers
/todos/${id}
- Le texte de la tâche a deux états : « normal » et « editing »
- htmx écoute l’événement de double-clic
- requête vers
/ui/todos/${id}?editable=true
- le Service Worker renvoie le HTML de
Todo contenant <input>
- htmx remplace l’élément de tâche actuel par le HTML de la réponse
Résumé
- Techniquement, cela fonctionne
- Est-ce une bonne idée ? Est-ce vraiment l’aboutissement d’une application fondée sur l’hypermédia ? Faut-il abandonner React pour construire ainsi ?
- Dans une application entièrement locale, l’indirection de htmx semble davantage pesante que libératrice
- La plupart des applications ne sont pas entièrement locales
- Le motif des « îlots interactifs » paraît préférable à une séparation du code « côté serveur » entre Service Worker et vrai serveur
- C’était une tentative expérimentale pour montrer qu’il est possible de construire une application monopage entièrement locale avec de l’hypermédia
Aucun commentaire pour le moment.