Services gratuits
Intégrer des maps à vos sites QR Code modifiable après impression Lien court personnalisable Générateur de de mot de passe Créer des images pour les réseaux sociaux Créer des palettes de couleurs harmonieuses Déminifiez votre code Créer des fichiers .gitignore facilement Système de réservation pour restaurantsSommaire
Coucou les loulous 😁,
Merci d'avoir cliqué sur cet article, j'espère qu'il vous plaira ☺️ (comme toujours).
Bon, de quoi on parle aujourd'hui ? Je ne sais plus moi, je suis perdu...
Ah si... de Stimulus et de quelques contrôleurs bien sympas que vous pourrez réutiliser dans vos applications.
Vous êtes prêts ? Alors c'est parti !
Comme vous le savez sûrement, Symfony depuis ses versions 6.x a lancé le projet Symfony-UX, j'en ai déjà à maintes reprises parlé sur ce blog.
Et pour ce projet, ils ont fait le choix d'utiliser la stack "Hotwired" (Stimulus et Turbo)...
Sauf que cette stack, elle ne vient pas de nulle part, en fait, elle vient du monde Ruby on Rails, c'est tout simplement le front par défaut fourni avec Rails (du moins, dans sa version 8.0).
Étant un grand fan de cette stack, j'ai décidé de vraiment beaucoup m'intéresser au monde de Ruby on Rails, et donc l'application que je développe actuellement est une application Ruby on Rails.
Cette application, c'est tout simplement la petite sœur de ViteUneTable, mais cette fois, pour les coiffeurs...
Son petit nom est "Coupéo", le .com est déjà pris 😛...
Pour mener ce développement à bien, j'ai dû réutiliser certains de mes contrôleurs Stimulus, en mettre à jour d'autres et enfin en créer de nouveaux.
Le fait que Rails et Symfony partagent le même front est super pour apprendre Rails, je n'ai que la partie Ruby et back à prendre en main. En ce qui concerne Turbo et Stimulus, je suis déjà à la maison.
Et en fait, même si au début Ruby est déroutant, c'est un vrai plaisir une fois qu'on est dedans (et merci aux IA pour leur aide à comprendre comment tout ça fonctionne).
Le problème des contrôleurs Stimulus, c'est qu'ils peuvent charger d'autres bibliothèques. Par exemple, vous pouvez parfaitement charger React depuis un contrôleur Stimulus.
Donc, si votre grosse application a plein de contrôleurs et que ces contrôleurs ont eux-mêmes des grosses dépendances, vous chargez 1 milliard de Javascript au début de la page.
Donc, il faut charger tout ça de manière asynchrone, on ne charge que quand on a besoin.
D'après mes recherches, ça n'a pas changé, il faut ajouter un commentaire "/* stimulusFetch: 'lazy' */" au-dessus de votre contrôleur.
Très simple et efficace. Après, je dois dire que le projet qui utilise Symfony-UX que j'ai, moi, utilise toujours webpack encore et j'imagine que les choses ont probablement changé avec AssetMapper.
Bon, là on ne va pas se mentir, c'est plus récent, donc je suis sûr de mon coup...
À l'heure où j'écris ces lignes, je suis sur Ruby on Rails 8.0.
Dans un premier temps, on va dire à importmap de ne pas précharger les contrôleurs Stimulus au premier chargement de la page.
Par défaut, importmap importe absolument tout, donc le navigateur se met à tout télécharger, ça peut vite devenir ultra lourd.
Très simple, à l'endroit où on définit nos contrôleurs Stimulus, on définit "preload: false".
Ça se passe dans le fichier : app / javascript / controllers / index.js
Si vous venez d'installer Rails, vous verrez que vous, vous n'avez pas le "lazyLoadControllersFrom", par défaut c'est du "eager".
En remplaçant les choses comme je viens de vous dire, vous chargerez vos contrôleurs quand Stimulus les voit dans l'HTML.
Dans le fonctionnement de Ruby on Rails 8.0, il n'y a aucune obfuscation du code JavaScript, le serveur vous envoie les fichiers tels que je les ai écrits.
J'ai décidé de complètement garder ce fonctionnement, j'aime bien l'idée que les gens puissent voir "comment ça marche".
Avant de vous partager mes contrôleurs, j'aimerais vous parler de Stimulus Components...
Vous allez trouver beaucoup de choses déjà prêtes à l'emploi dessus, comme un "auto submit" ou encore une intégration avec Chart.js.
Allez, c'est dans cette section que vous allez pouvoir retrouver le code des contrôleurs.
Tout comme ViteUneTable, l'assistant de réservation de Coupéo est en fait une Turbo Frame. Pourquoi changer quelque chose qui marche ? 🙂
Le seul truc, c'est que dans le header, j'ai un bouton qui ne doit s'afficher que sur la landing... J'ai besoin qu'il disparaisse quand l'URL ne match plus.
Pour ça, on intercepte les événements Turbo...
Une petite démo ?
Et maintenant, le code :
On commence par le contrôleur que j'utilise sur Coupéo, pour la version mobile du choix de l'heure du rendez-vous.
C'est une interface super chiante à faire en mobile mais avec un petit contrôleur Stimulus, ça va tout seul.
Et voici le code :
Cet été, LFMaps est sorti, c'est simplement une instance hébergée d'OpenFreeMap...
Et j'en avais personnellement besoin pour Coupéo 😁.
Sur la landing page des salons, on peut voir la carte et où ils se situent. Une démo ?
Et c'est parti pour le code, par défaut il charge les tiles de LFMaps.
Vous vous souvenez... c'était en 2022.
Et bien, sa nouvelle version est arrivée, fonctionnant avec la dernière version d'intl-tel-input...
Ça donne quoi ? 😛
Et le code ? Attention à l'URL des "Utils". Aussi, pour rendre tout ça compatible avec Rails, j'ai choisi la facilité et mis la traduction directement dans le fichier.
Pensez bien à rendre les fichiers .webp des "flags" accessibles.
On parle de l'anti no-show de ViteUneTable et Coupéo... 🙂
Une petite démo ? 😁
Et le code du contrôleur. À noter ici que j'utilise "window.Turbo", car Rails par défaut l'expose avec le package "@hotwired/turbo-rails".
Nous y voilà, les contrôleurs vous sont donnés tels quels, tels qu'ils sont dans Coupéo...
Il vous faudra les adapter à vos besoins... mais ça vous fait une base si vous le voulez.
Passez une très bonne journée et à la prochaine ! 😁