Stack JS - Githubissues

Problème précis :

[x] pour des raisons de licence il faut migrer de mapbox. Solution envisagée vers libremap en v2 [qui a le support ie11]. TODO: faire la migration, bravo @tchak qui est deja dessus #6876
[x] passer à typescript (confort de code) bravo @tchak qui est deja dessus #6876
[x] le build est lent en CI est lent. Solution migrer de webpack vers vite-rails qui est basé sur esbuilt pour de la compilation rapide (plus des hooks pour étendre le support du JS généré par esbuilt ex ; support IE 11 ?). question, est-ce vraiment plus rapide avec vite-rails ? TODO: vérifier que le build va plus vite -> voir en équipe une fois libremap/typescript rdy (et typescript est conditionné a la facilité d'intégration via webpack)
[x] pour des raisons de vélocité, doit-on arreter le support IE 11 ? il semblerait qu'il y ait 4% de la base utilisateur (cf: matomo). TODO: instrumenter les profils utilisateurs (custom variable matomo) @mfo -> je propose d'installer le tag manager matomo pour mettre une custom var a nos utilisateurs [ une fois connectée, plugger le tag manager ]
[x] nous constatons une complexité croissante sur la stack JS (plusieurs frameworks: ujs, du JS global, du react). La crainte est de voir cette compléxité aller de malle en pire. L'idée actuelle est de simplifier la stack par l'usage de turbo. TODO: un POC turbo pour remplacer du JS global [@kemenaran ; chaud ?]
[x] favoriser des solutions tech minimaliste [ex: dropdown -> une liste de bouton] ; voir passer par des concepteur aguerries en a11y/UX pour simplifier des problématique d'interface [@mfo ; p-e une question à aborder avec l'ux a venir ?]
[x] se débarrasser de l'évènement ds:page:update #7186
[ ] se débarrasser du namespace DS.*
[ ] replacer les link_to method: * par button_to method:* afin de pouvoir activer turbo sur le body

pour le sujet IE11 ; on peut instrumenter les comptes via une custom variable matomo afin d'en avoir le coeur net si vous le souhaitez. ex d'implem : https://github.com/betagouv/monstage/blob/staging/app/views/layouts/_analytics.html.erb#L9

Point de détail : je suis pas trop chaud pour intégrer le tag manager de Matomo :

parce qu'idéalement notre matomo devrait pouvoir être ouvert
parce que ça m'inquiète qu'on mette en place une solution où des gens pourraient injecter du JS dans DS sans que ça apparaisse dans le code source.

Mais en revanche chaud pour une variable custom mise directement dans le code.

Pourquoi ?

L’arrivée prochaine du chantier des champs conditionnels avec son lot de dynamisme dans les interfaces nous a incités à porter le regard sur notre stack “frontend".

Turbo

La semaine dernière j’ai travaillé sur l’introduction de turbo dans le projet. Je vous fais ici un retour. Sous le nom turbo en réalité se cachent plusieurs technologies. Les plus importantes c’est turbo-drive, turbo-stream, turbo-frames et stimulus. Je vais vous en dire deux mots sur chacune :

turbo-drive c’est le successeur de turbo-links mais avec les <form> en plus. La techno est censée aussi remplacer les data-* de rails-ujs. Mais il y a des limitations. Le data-deisable n’existe plus. On ne peut pas avoir de data-confirm sans le comportement “remote”. Et l’usage de data-method sur les link_to est fortement découragé.
turbo-stream c’est un format pour envoyer des actions depuis le serveur vers le client pour appliquer des modifications sur le DOM. Ça remplace le fait d’envoyer du js. C’est bien plus propre. Mais officiellement il n’y a pas de moyen d’ajouter des actions custom. Dans une PR je contourne cette limitation et j’ajoute un moyen d’implémenter des actions custom.
turbo-frames je n’ai pas encore trop touché, mais en théorie c’est comme les <frame> mais en plus moderne.
stimulus c’est un framework js qui permet d’annoter le DOM avec des actions déclaratives. Le principal intérêt c’est que c’est basé sur MutationObsever et donc pour faire du "sprinkle” ça évite de se baser sur les événements du type after render. Je me suis servie pour instancier nos composants react plutôt que de le faire sur les événements.

L'existant

Le constat que je fais c’est qu’aujourd’hui nous avons beaucoup de manières différentes de coder des interactions dans DS. En introduisant turbo j’aimerai qu’on en réduise le nombre de techniques et pas qu’on ajoute juste une autre.

Aujourd’hui, nous avons plusieurs techniques en place :

rails-ujs c’est ce qui permet l’usage des attributs data-remote, data-confirm, data-method, data-params et data-disable. Nous avons aussi une extension pour l’usage de data-remote sur les <input> avec un data-debounce.
Nous utiliserons de manière extensive le format :js dans les réponses serveur pour modifier le DOM. Nous avons une série de helpers qui nous permet de faire des opérations standards sur les éléments DOM.
delegate() : on utilise de manière extensive des “sprinkle" de js via la délégation. On utilise aussi l’événement ds:page:update pour certaines interactions qu’on ne peut pas faire via la délégation.
DS.* : C’est un namespace global qui contient des fonctions qu’on utilise via onclick=DS.myAction(); dans les templates.
react : Nous avons des composants react qu’on instancie via un helper dans les templates react_component(“Mycomponent”, {}). Ces derniers sont utilisés pour les ilots d'interactivité comme les autocomplets ou la carte. Ils s'en servent souvent d'événement globaux et de requêtes au format :js pour interagir avec le reste de l'application.

“Le dogme DHH”

Comme je l'ai expliqué plus haut, turbo c'est un ensemble de techniques qui peuvent être utilisées de manières différentes. Il y a le dogme officiel DHH/Rails. Tel que je le comprends c'est :

activer turbo-drive
utiliser turbo-frames autant que possible
utiliser turbo-stream quand vraiment vous ne pouvez pas faire de turbo-frame
utiliser stimulus pour de l'interactivité dans le navigateur ou si toutes les autres approches ne fonctionnent pas

Le premier soucie dans notre cas c'est l'existent

Il faut migrer ce que nous avons vers une des techniques de turbo.

Le plus direct c'est de migrer ujs + format :js vers turbo-drive + turbo-stream. J'ai un peu commencé. La principale difficulté est dans le fait que c'est risquer d'activer turbo-drive sur l'ensemble d'une vieille app comme la nôtre. Il faut donc activer turbo-drive au cas par cas en remplaçant data-remote et data-confirm par data-turbo et data-turbo-confirm. Ce n’est pas trivial, car la logique d'application déclarative n'est pas la même qu'avec ujs – ce n’est pas l'élément interactif qui doit porter data-turbo=“true”, mais un de ces parents. Donc relou, mais pas impossible.

Les interactions bindé sur ds:page:update doivent être supprimé, car turbo-stream ne sait pas emmètre d'événement à la suite de remplacement de DOM et incite à utiliser stimulus qui se base sur les MutationObserver pour ajouter de l'interactivité. L'approche par délégation continue de fonctionner aussi évidemment. C'est la raison pour laquelle nous avons migré l'instanciation des composants react vers stimulus.

L'approche par délégation pose le problème de maintenabilité – il est difficile de savoir quand un snippet n'est plus utilisée. Donc mon souhait sera de s'en éloigner de cette approche. Enfin les onclick via le namespace DS.* pose un soucie similaire même s’il est un peu plus facile de trouver les usages du code avec un grep.

Le deuxième soucie c'est l'alignement dans l'équipe

Mon expérience des discussions avec vous c’est que nous avons des sensibilités très différentes vis-à-vis de la manière la plus confortable de faire du frontend. Pour être honnête, ce problème existe aussi pour la partie backend, mais Rails (pour le meilleure et pour le pire) fait un meilleur job de proposer des solutions “clés en main” sur la partie backend. turbo est clairement une tentative par Basecamp de proposer une solution “clés en main”. Les retours que j'ai pour l’instant c'est que les nouveaux projets alignés sur le dogme DHH se passent raisonnablement bien. Mais dans notre cas on ne peut pas faire l'abstraction de l'existent et l'énergie disponible à mettre dans la migration est limité.

Nous avons besoin de nous aligner dans l’équipe sur ce vers quoi on veut y aller. Je veux bien faire du taff pour migrer, mais j'ai besoin de motivation de votre part. Si je devais faire la migration à la sauce "Tchak" ça ne ressemblerait pas au dogme DHH. Si vous voulez le dogme DHH il faut le dire clairement pour que je sache pourquoi je le fais. Peut-être que ce dogme est finalement la seule solution pour trouver un accord. Car ce que j'entends quand je demande "vous voulez quoi pour faire du frontend ?" on me répond "je veux le code le plus simple possible". Ça ne m'aide pas. Nous n’avons clairement pas la même définition de "simple". Mon "simple” à moi serait de migrer progressivement vers du React SSR. Ce n’est clairement pas celui de l’équipe 🤣 C'est normal. J'ai donc besoin de savoir si vous voulez qu'on essaye un tour de table pour arriver à un set de pratiques (autour de turbo) ou vous pensez qu'on n’arrivera pas à se mettre d'accord et qu'il faut juste appliquer le dogme DHH ?

Pour prendre un exemple – personnellement la partie qui me pose le plus de problèmes dans turbo c'est stimulus. Les <button data-controller="toggle" data-action="click->toggle#onClick" data-toggle-value="true" /> je trouve ça imbitable et inmaintenable. Qit à faire du turbo je préfère un button_to avec turbo-drive avec dans un controller un render turbo_stream: turbo_stream.toggle('.card') ce qui serait évidemment très controversé. Mais peut être que ce type d'interaction (interaction entre des éléments dans la page) peut être modélisée via les turbo-frame ?

en gros dsl mais je suis en boucle la dessus.

TLDR ; dans le fond : je pense que l'interactivité portée par le JS sur une page web est over rated (ok pour du FB ou des sites qui sont des apps genre, mobile. la on est sur une app metier. un cycle de vie complet client/server me semble être ce qui reste de plus productif/facile/maitrisable tout en étant acceptable par l'utilisateur).

concernant la substance de ma position et ton push :

déjà bravo de mettre ça en place ; je pense que sur le conditionnel l'outil tombe a point.
tant qu'a refactorer du JS (donc l'existant), mon avis c'est de voir avant avec Olivier si on ne peut pas simplifier l'interface (afin de virer des parties en JS). il y a plusieurs sujets autour de ça : je garderais les ilots react et le mix turbo (j'ai apprécié stimulus pour eviter les "soupes" de namespace globaux ou de delegation en vrac). le reste -> bye
pour le choix des technos, si par react/SSR tu entends une simili SPA ; pas ma tasse de thé

Je vais apporter une précision. Quand je dis :

Mon "simple” à moi serait de migrer progressivement vers du React SSR

J'entends une solution basée soit sur remix soit sur juste la nouvelle version de react-router (remix sans la partie compilateur/serveur)
Je pense que dans l'application DS il y a deux parties :
- L'interface usager – cette partie selon moi devrait pouvoir fonctionner en mode dégradé sans js (faire l'effort d'implémenter un flow alternatif au autocomplete par exemple) mais en conditions normales d'usage elle devrait bénéficier de “progressive enhancement”.
- Les autres interfaces (instructeur/administrateur) – elle pourrait être même une SPA pure. Mais avec une techno comme remix la question ne se pose pas – tout est SSR. Dans tous les cas, je ne ferai pas l’effort (très couteux) sur cette partie de faire fonctionner l’application en mode dégradé sans js.
Avec une techno comme remix la migration serait extrêmement progressive (page par page) avec une technique d’application “ombrelle”.
Ce point de vue n'est absolument pas partagé dans l'équipe. C'est juste pour illustrer les différents points de vue et sensibilités dans l'équipe.

Merci pour ce travail.

Concernant une spa

Dans mon lointain souvenir ou je faisais du js, on était obligé de modéliser le métier coté back et front, avec des points de frictions entre le 2.

Dans la mesure ou on garde le back en rails, on aura a nouveau ce pb. je suppose qu'il est plus coûteux que l'utilisation de la full stack rails DHH.

Concernant une intégration partielle

@tchak , je n'ai pas bien compris, tu proposes du remix pour une intégration partielle ou tu trouves cela pertinent uniquement pour une spa ?

@LeSim Je ne préconise pas une SPA. Tu à raison que s'il faut modéliser le métier deux fois c'est null. Je vous ai préparé une demo pour illustrer l'usage possible de remix avec rails. Oui, ça suppose qu'il y a un serveur node entre l'app rails et le navigateur.

Backend : https://github.com/tchak/rails-remix-demo/blob/b6bf791aa73979dff14ef48c943ddae73bffe42e/app/controllers/todos_controller.rb Frontend : https://github.com/tchak/rails-remix-demo/blob/b6bf791aa73979dff14ef48c943ddae73bffe42e/app/frontend/routes/index.tsx

Pour moi l'avantage de cette solution c'est que l'UI est complètement déclarative, dynamique, typée et fonctionne sans JavaScript en dernier recours. Toutes les interactions sont faites via les form et donc peuvent être envoyées directement vers rails. Il n'y a pas de “state management” coté JavaScript. La session est gérée par rails aussi. Le node ne fait que crasher du HTML et optimise les transitions (si le JavaScript est disponible). Mais les réponses de rails c’est du json et des redirects sans aucune “magie”. Ce que j'appelle "optimise les transitions" c'est que si le JavaScript est chargé sur la page les submit se font via fetch (comme avec turbo) et le serveur node intercepte les redirections et retourne une 204 avec un header spécial qui fait que le redirect devient un fetch en arrière-plan suivi d’un update de l'état de la page.

Et ce que vous pouvez voir aussi dans ma démo c'est le fait que les pages qui ne sont pas implémentées dans remix sont simplement servies depuis rails. C'est ça que j'appelle l'application "ombrelle". Donc il est possible de migrer page par page. En théorie la migration c'est de porter une page de haml vers tsx et de mettre les variables d'instance dans le controller dans un render json.

Je pense qu'il faut qu'on ferme cette parenthèse sur les SPA/remix. Quelle que soit ma conviction sur ce qui serait “le monde idéal”, il faut qu'on avance de manière pragmatique.

Je pense que l'usage des view_components sera un bon pas en avant. J'ai un plan pour faire en sorte que les view_components puissent utiliser React et Stimulus en fonction des besoins. Si déjà on arrive à ça en se débarrassant de tout le js ad hoc, ça va être top.

demarches-simplifiees / demarches-simplifiees.fr

Stack JS #6849