Re: [conception] Un plugin Progressive Web App commun en coquille vide ? (1 SW 2 rule dem all)

Hello,

pour répondre "oui et non" parce que la vie c’est pas simple :)

Pour le Oui :

1/ il y a dans offline déjà tout le mécanisme dont tu parle dans https://git.nursit.net/open/offline/-/blob/master/action/api_offline.php :

• l’api avec routeur vers des methodes extensibles
• le builder de l’installeur, du service worker
• la gestion de l’installation, la désinstallation via https://git.nursit.net/open/offline/-/blob/master/offline_pipelines.php

2/ il suffirait donc de l’extraire en le prefixant de manière plus générique en offrant des pipelines pour construire la liste des JS a inclure dans le build (mais il faut construire une liste de JS ET une liste d’arguments à passer, qui seront ajoutés sous forme de tableau de config js)

3/ il manque un mécanisme d’auto-destruction du service worker
C’est fil qui me l’avait suggéré, et au retour d’expérience ça semble totalement indispensable : quand on envoie un service worker chez le navigateur client, il s’installe et a sa propre vie, autonome. Si on envoie un bug, notamment autour de la mise à jour, c’est mort : le service worker ne se mettra jamais à jour, le client est planté à jamais, sauf à faire un shift+reload, ce qu’un•e utilisateur•ice normal•e ne fera jamais.

La bonne parade c’est donc que le service worker soit toujours envoyé avec une date de péremption, éventuellement configurable. Cela l’oblige à se mettre à jour tous les X jours, mais cela garanti aussi qu’en cas de gros bug les effets indésirables ne dureront pas plus longtemps

Pour le Non :

1/ de ce que j’ai vu dans l’utilisation des services workers c’est que c’est vraiment pas simple à faire marcher de façon fiable, super compliqué à débuguer vu que tout se passe dans les navigateurs clients, avec toute leur diversité, et qu’on a aucune info en feedback (à part quelqu’un•e qui va dire « ça marche pas » ou «  je tombe tout le temps sur la page 404 », sans moyen de savoir ce qu’il y a de stocké dans son navigateur)

2/ de là je suis très frileux à voir plusieurs plugins ajouter leur JS et vogue la galère en espérant que tout marche bien à l’aveugle alors que déjà tu as du mal à faire marcher le truc correctement en maitrisant tout le code (autant croire au miracle)

3/ je trouve que ces plugins qui reposent sur un plugin qui doivent installer un plugin… etc pour s’installer c’est bien lourd. J’ai encore un peu en travers de la gorge le mini-calendrier extrait du plugin agenda « parce que bon c’est générique et d’autres en auront besoin » qui pourrit la vie des utilisateur•ices du plugin agenda depuis à peu près 14 ans sans que jamais aucun autre plugin n’ait utilisé ce fameux mini-calendrier

4/ je sais pas trop comment proposer une solution propre de partage


En conclusion j’ai envie de dire : avant de faire un plan à 20 ans pour que tout puisse s’assembler dans un monde idéal, et alors qu’on a pas de retour d’expérience sur le sujet, avançons donc sur les différents sujets en parallèle, et quand on comprendra tout comment ça marche bien, on aura sans doute une idée plus claire de ce qu’il faut mutualiser, ce qu’il faut séparer etc...

(et peut-être que d’ici là on aura avancé sur l’utilisation de composer ?)

--
Cédric
Le 25 juil. 2020 à 11:02 +0200, RastaPopoulos <[email protected]>, a écrit :
>
> Après une semaine de diverses recherches, voici où j'en suis. Celleux qui s'intéressent à la question (notamment Cédric car Offline), merci de me dire ce que vous en pensez. :)
>
> Rappel : une PWA, ce n'est pas une fonctionnalité précise, mais un ensemble de fonctionnalités JS qui augmentent les capacités d'un site web pour lui permettre des choses que seules les applis natives pouvaient faire avant. Et comme son nom l'indique : ça peut être progressif, on peut ajouter petit à petit des choses. Ça peut être :
> - garder en mémoire des pages pour lire même déconnecté
> - synchroniser des données régulièrement
> - s'inscrire à des notifications push (qui arrivent donc même quand on n'a pas ouvert le site)
>
> Point important 1 : on peut vouloir *une seule ou plusieurs* de ces fonctionnalités. C'est forcément modulaire, ya aucune obligation d'avoir tout.
>
> Cependant elles utilisent un truc commun : un service worker, un programme JS qui tourne chez la personne en parallèle du site.
>
> Point important 2 : il ne peut y avoir QU'UN service worker pour une même "branche" de l'arbo des URL. Et par défaut la portée est celle du dossier/URL où se trouve le fichier JS. Par exemple s'il est dans exemple.com/javascript/sw.js alors par défaut il ne pourrait servir que pour les requêtes sous exemple.com/javascript/… Si le fichier est à la racine du site, alors la portée par défaut est "tout le site".
>
> Le plugin Offline de Nursit, fait pour le Diplo et utilisé en test grandeur nature sur Contrib, ajoute la fonctionnalité "lecture hors ligne" :
> https://git.nursit.net/open/offline
> (au passage maintenant qu'on a git, est-ce qu'il pourrait être dans la communauté ?)
>
> Ce plugin ajoute donc UN service worker, pour TOUT le site, mais seulement pour la fonctionnalité "hors ligne". Du coup quand on veut ajouter une autre fonctionnalité, les pushs par ex, il est impossible d'avoir un autre SW pour la même portée. J'ai bien cherché s'il était possible de coder les pushs dans un SW avec une portée bidon car ya pas à capter les requêtes (événement "fetch") on s'en fout. Mais impossible d'avoir une réponse exacte à ça et la doc dit plutôt le contraire :
> https://developer.mozilla.org/fr/docs/Web/API/PushEvent
> > Cet événement est envoyé au scope global d'un ServiceWorker
>
> Je propose donc que SPIP ait un plugin "pwa" commun, qui va mutualiser :
> - la génération d'un fichier JS de service worker ayant une portée globale
> - mais ce fichier serait VIDE par défaut, et ce sont à des sous-plugins comme Offline ou Webpush d'ajouter du JS pour capter des événements dedans (qui "fetch", qui "push", etc)
> - l'inscription de ce SW dans le site
> - la désinstallation
> - la gestion de la version, comme le fait déjà Offline et donc la mise à jour chez les gens : cela se ferait si on ajoute ou retire un sous-plugin qui s'insère dans son JS + quand des sous-plugins le demandent en plus (comme Offline quand on a une version de site qui change)
> - comme ce serait LE plugin commun, c'est aussi là qu'on déclarerait le "manifest" permettant d'installer le site-appli sur l'accueil des mobiles (comme tout autre appli)
>
> Il faudra donc modifier Offline pour s'insérer dedans, et non plus fournir son propre service worker.
>
> --
> RastaPopoulos
>
> _______________________________________________
> liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> doc: https://www.spip.net/
> dev: https://core.spip.net/
> irc://irc.freenode.net/spip