Charger Trix (et donc Action Text) de manière asynchrone

Coucou, les petits loups 😄,

Merci d'avoir cliqué sur cet article, j'espère qu'il vous plaira 🙂.

Dans cet article, on va parler de ce petit éditeur de texte Wysiwyg, j'ai nommé Trix .

(Il est super sympa en plus)

Vous êtes prêts ? Alors, c'est parti 😄.

Ruby on Rails ?

Ouais, alors, ça ne vous aura sûrement pas échappé, mais Trix, il est très proche de l'univers Ruby On Rails.

Il est possible, je dis bien possible que je m'y sois mis récemment, et je m'amuse beaucoup, plus tard, il y aura un article complet sur RoR.

Mais pour l'heure, durant le dev de mon application, je suis tombé sur des choses sympas à raconter, d'où l'article que vous êtes en train de lire.

Petit indice, la nouvelle application RoR, sera pour les coiffeurs... 😁

Comment on utilise Action Text ?

Rails, est incroyable, que je vous explique...

Pour ajouter un éditeur de texte riche à une ressource (une entité pour les gens de Symfony parmi vous), ça se fait en trois minutes.

On ajoute Action Text au projet

Première étape donc, il suffit d'ajouter action text avec une simple commande.

(Ça va vous suivez jusque-là, c'est pas trop dur ? 😂)

On dit simplement à Rails qu'on veut un texte enrichi

Alors, là vous n'êtes pas prêts, ça va être d'une difficulté...

Non, je déconne 😁, c'est une ligne à ajouter à votre modèle.

Oulah, on a failli se faire un nœud au cerveau là, non ? Oui non mais moi aussi tant de simplicité ça me fait quelque chose...

On met à jour notre formulaire

Attention ! Là c'est technique, je sais pas trop si vous êtes prêts, ah bah non... toujours pas en fait 😂

Ouais, non mais je sais pas quoi vous dire moi, les mecs, ils aiment pas faire compliqué, c'est tout 😁.

Le formulaire est prêt

Bon bah, café ? 😁

Le coût de la simplicité

Bah oui, hein... forcément.

Dans la vie, rien n'est gratuit et si de notre côté c'est ultra sympa (franchement ça m'a tué de rire quand j'ai vu à quel point c'est simple...), de l'autre côté il y a un coût caché.

Une grosse bibliothèque javascript à charger, au chargement de la page

Le problème, il est là, Trix est très complet et très bien mais, forcément il est lourd à charger

Dans mon application, par défaut ça fait 512ko à charger en plus au chargement initial de l'application (quand une personne arrive pour la première fois).

Sur une connexion 4G pourrie, c'est pas acceptable...

On réduit ce coût ?

L'idée est simple, Trix, on n'en a pas besoin tout le temps, on en a juste besoin quand un formulaire avec une "Rich text" est affiché à l'écran

Du coup, pourquoi le charger au chargement initial ? Autant attendre le moment où il sera présent

Mise à jour de l'importmap

Sur Rails (et Symfony aussi avec Asset Mapper), on n'utilise plus "builder javascript", ça simplifie l'application et c'est pas plus mal.

Dans le cas de Rails, on va mettre à jour notre fichier importmap.rb.

Par défaut, une application Rails précharge tout ce qu'il y a dans l'importmap, l'idée ici est tout simplement de mettre "preload" à false pour dire à Rails qu'on ne veut pas précharger Trix et Action Text.

Et dans mon exemple, vous voyez que je ne précharge pas mes contrôleurs stimulus non plus.

Si on jette un œil au code source de la page générée, on voit bien toutes nos lignes dans la balise de l'import map, mais, en dessous, on voit qu'ils ne sont pas tous préchargés, seulement les essentiels.

Et d'ailleurs, dans les modules préchargés, on voit un truc : turbo-helper, je me demande bien ce que ça peut être.

Charger Trix au moment opportun, on aide Turbo ?

Ahhh ! Le retour du Turbo-helper, la dernière fois que je l'ai utilisé c'était sur href="https://veloenfrance.fr/" target="_blank"> Vélo en France.

L'idée de ce petit fichier, c'est d'accompagner Turbo, pour par exemple fermer des "modals" ou des alertes avant la mise en cache de Turbo.

Quand on revient sur une page, Turbo ré-affiche ce qu'il a en cache avant d'aller chercher le HTML sur le serveur, enfin, c'est plus tout à fait vrai, car maintenant, sur tous les "get", il va faire un prefetch, ça veut dire que si votre application utilise des "get" pour modifier des données (pas bien ! Bon, je vous avoue je le fais sur le site sur lequel vous êtes actuellement, mais, on va pas en parler !). Dans ce cas-là, le prefetch de Turbo cassera complètement les modifications de vos données.

Ici, nous allons simplement utiliser Turbo-helper pour accompagner le changement de contenu quand Turbo pousse du nouveau contenu sur le DOM.

Si on détecte Trix dans ce contenu, alors, on le charge !

Et voilà !

Petit bonus : Empêcher le "cumulative layout shift"

Et oui ! Le temps que Trix se charge, notre "textarea" est plus petite, donc à un moment, la page va sauter, ce qui n'est pas beau esthétiquement...

Pour régler ce petit problème, il suffit juste de mettre une hauteur minimum à la div qui entoure notre textarea, avec Tailwind, c'est "min-h-[150px]"

Et hop ! Plus de saut !

Conclusion

C'était le premier article (avant beaucoup d'autres je pense), sur Ruby on Rails !

On reste dans le même univers que Symfony sur bien des aspects, d'ailleurs, Symfony n'est pas étranger à mon intérêt pour Rails.

Le front de Symfony-UX... c'est celui de Rails en fait ! Comme à la maison !

Je vous souhaite une très bonne journée et à la prochaine 😁.