Re: [conception] Un plugin Progressive Web App commun en coquille vide ? (1 SW 2 rule dem all)
RastaPopoulos <[email protected]>
| Newsgroups | gmane.comp.web.spip.devel |
|---|---|
| Message-ID | <[email protected]> |
(répondre sur la liste :p) Le 28/07/2020 à 11:55, Cerdic a écrit : > Ah ben si c’est ça ton soucis et ton use case de maintenant, on peut ajouter facilement une extensibilité de offline. Bah disons que c'est *un* des soucis (pour avant-hier :p) J'ai bien vu déjà tout le bazar de gestion complète (installation, mise à jour, désinstallation) du service worker dans Offline, qui est déjà pas mal complet et ça c'est super ! Au delà de l'aspect choix des utilisateurs (proprio qui veut une seule ou plusieurs fonctionnalités nécessitant un SW) qui implique une conception modulaire, même juste de notre point de vue dév maintenance du code, vu que d'autres événements (push ou autres) en ont obligatoirement besoin aussi, je m'étais dit que ça serait justement peut-être plus clair, plus facile à maintenir si c'est découpé : - tout le code qui est propre à la gestion, quelque soit le contenu - VS le code propre à chaque besoin, Offline qui gère le fetch etc (par ex il pourrait y avoir des logs différents pour chaque morceau et donc suivant ce qu'on voit, on saurait si ça vient du plugin central ou de Offline ou de Push). Mais pour l'instant de ton côté tu as l'air de penser que ça serait plus compliqué, ce que je comprends. :) (Et pour revenir sur le point Non-2, je ne crois pas qu'il y ait "plusieurs plugins" au sens "plein" qui vont s'insérer dedans et qu'on contrôle rien : ce sont forcément quelques rares plugins qui "se connaissent" et qui vont faire en sorte de travailler ensemble, genre 2 ou 3 max. Le découpage proposé est là pour permettre d'avoir seulement ce qu'on veut, car mise à part le SW au cœur, chacun n'a aucun rapport, c'est des fonctionnalités totalement différentes, possiblement avec des tables SPIP, etc.) À court terme, si déjà un plugin Push peut profiter immédiatement de ce qui existe et gérer ses événements à lui dans le SW, moi ça me va hein. On pourra découper mieux plus tard… > Mais comme je le disais, offline n’est pas encore super fini, il reste des soucis, il y a besoin de debug, ce qui prends du temps, et je suis moyennement confiant sur le fait qu’ajouter des js en plus aide... Bé pour un site j'ai vraiment besoin de Offline *et* de Push, donc je vois pas comment on… enfin au moins moi, je pourrais faire l'économie d'avoir plus de JS… :( Pour Offline en particulier ça tombe bien, on peut aider à faire des retours, puisque besoin sur un site avec pas mal d'articles et beaucoup de visites. Une des grosses différences que je crois voir, c'est que pour le Diplo c'est un mensuel, et donc peu de changement éditoriaux (on peut se permettre de changer manuellement la "version éditoriale" quand un nouveau numéro sort), alors que nous ya des nouveaux articles tous les jours, possiblement plusieurs fois par jour (l'accueil change tout le temps quoi). Et ya évidemment besoin que les gens puissent garder en mémoire au moins l'accueil + les articles liés dans l'accueil, quand ils ont une connexion, pas juste une fois par mois. Mais bon on verra plus tard pour Offline, la priorité c'était surtout la structure générale, et le fait de pouvoir avoir *en même temps* qu'Offline un autre plugin qui permet de s'abonner à des pushs. :) -- 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