Dialog, l'élément HTML natif pour les modals et boîtes de dialogue, supporté partout depuis mars 2022

Coucou les loulous 😁,

Merci d'avoir cliqué sur cet article, on reste dans le web et j'espère que ça vous plaira ! 🙂

Aujourd'hui on va parler d'une API web que j'aime beaucoup, et qui est maintenant bien supportée par les navigateurs, l'élément dialog.

Vous êtes prêt ? Alors, c'est parti ! 😉

Pourquoi cet article ?

Comme vous le savez probablement déjà, en ce moment je travaille sur Coupéo, le ViteUneTable mais pour les coiffeurs cette fois.

Et ma stack de prédilection en front, reste la même, Hotwire (Turbo et Stimulus).

Le backend, quant à lui il a changé, c'est Rails, mais bon ça ne nous intéresse pas vraiment pour aujourd'hui.

Turbo confirm...

Dans l'application parfois, j'ai besoin de demander confirmation avant une action, par exemple, quand l'utilisateur veut supprimer quelque chose.

Le truc, c'est que, par défaut, turbo utilise une alerte pour la confirmation...

Et j'ai toujours détesté les alertes...

Ça ne date pas d'hier, j'ai toujours trouvé cette méthode horrible, déjà en 2012 je trouvais que c'était nul...

Dans mes anciens projets (par exemple ViteUneTable), j'utilisais SweetAlert2, que je chargeais de manière asynchrone, parce qu'il faut avouer que les alertes sont jolies mais ça en fait du Javascript et CSS à charger...

Le projet étant un projet Rails et la communauté étant énorme, je me dis "quelqu'un d'autre a dû avoir le problème... comment ils ont réglé ça ?"

En cherchant un peu je suis tombé sur ce code, parfaitement intégré à Hotwire.

Et concrètement, quand on regarde ce code, il remplace la fonction de Turbo (celle qui fait appel aux alertes) par une fonction qui utilise l'API Dialog du navigateur.

Je l'ai donc intégré au projet (la capture d'écran plus haut), et j'ai décidé d'aller bien plus loin avec cette API.

Pourquoi je n'aime pas du tout alert() ?

L'expérience utilisateur est atroce, ça sort l'utilisateur de "l'ambiance" de l'application, il y a cette interface éclatée au sol qui pop de nulle part... D'un point de vue UX, c'est une solution de facilité qui est vraiment pas bonne.

De plus, c'est bloquant, quand vous faites appel à alert() vous bloquez tout le code qui est derrière, le JavaScript étant de base un langage qui est conçu pour être asynchrone (vous ne pouvez pas bloquer l'interface utilisateur comme ça), je trouve que cette fonction fait tache dans le monde de JavaScript.

L'élément et l'API dialog

Il ne fait que remplacer alert() ?

Absolument pas, en fait, moi ça a été mon point d'entrée, comme expliqué plus haut, mais si vous avez travaillé avec les "bootstrap modal" alors, vous pouvez les remplacer par cette API native pour faire des interfaces plus compliquées qu'une simple confirmation.

D'ailleurs, vous pouvez voir que DaisyUI utilise les dialog(s).

Concrètement comment ça marche ?

Tout d'abord, sur votre page il vous faudra un élément de type <dialog>, qui est bien un élément HTML valide.

Un petit exemple ?

Ça c'est le dialog de confirmation que j'utilise avec Turbo.

Et là la magie c'est que maintenant avec cet élément vous avez plusieurs fonctions disponibles... en JavaScript.

Oui, oui ces fonctions sont directement exposées par le navigateur, pas besoin de bibliothèque en plus...

On reparle plus tard des différences fondamentales entre les méthodes disponibles...

Comment j'utilise les Dialog avec Hotwire (Turbo et Stimulus) ?

Avant tout vu qu'une image vaut mille mots, voici une démo de ce qui se passe quand je clique sur "nouveau service" dans l'interface de gestion de Coupéo.

Donc, qu'est-ce qui se passe sur ce GIF ?

Dans le lien du bouton "nouveau service", c'est un GET c'est pour ça qu'on voit qu'avant que je clique Turbo précharge les données depuis le serveur, j'ai dit à turbo que la cible de ce bouton est la turbo-frame "modal" qui est incluse dans le layout de la partie management de cette application.

Le serveur va répondre quelque chose dans ce genre-là :

Comme vous pouvez le voir, c'est du HTML, le layout est simplifié car Rails est configuré pour renvoyer un layout vide quand la requête contient l'identifiant d'une turbo frame.

Et dans ce layout, il y a notre turbo-frame avec notre dialog dedans.

À ce moment-là, c'est bien nous avons donc notre dialog dans la page, mais il ne va pas s'ouvrir...

Rappelez-vous, pour l'ouvrir, il nous faut un peu de JavaScript.

Si vous êtes observateur, vous avez vu qu'à ce moment-là, un contrôleur Stimulus se charge, ce contrôleur va faire le travail pour nous.

Et voici le code de mon contrôleur Stimulus :

Quand, Turbo injecte dans le DOM notre dialog, Stimulus voit qu'il fait appel à un contrôleur, le contrôleur "dialog".

Il charge donc notre contrôleur et appelle la méthode "connect", la méthode connect se charge pour nous de charger la méthode Javascript "showModal()", ce qui a pour effet, d'afficher le modal... tout simplement.

Également, le contrôleur Stimulus s'occupe de la fermeture de notre modal, quand on clique sur annuler ou quand on annule, juste après d'ailleurs il nettoie la turbo-frame.

Le nettoyage de la turbo frame pourrait se faire avec une requête HTTP et Turbo, mais ça n'avait pas trop de sens... si je peux économiser une requête HTTP autant l'économiser.

Et voilà !

La différence entre showModal() et show()

On en a parlé plus haut, il y a deux fonctions pour ouvrir un dialog...

Voici un exemple bien parlant, de showModal.

Ici, on voit que le dropdown de intl-tel-input finit derrière le modal... Pourquoi ?

En fait ! quand on utilise showModal, le navigateur crée le backdrop tout seul, et met le modal par-dessus, peu importe le z-index, le modal n'est pas vraiment "dans le DOM" il est à part, au-dessus...

C'est pourquoi, vous ne pourrez jamais mettre quelque chose "par-dessus votre modal".

Conclusion

Et voilà, plus aucune excuse pour utiliser des alert() ;

On se retrouve prochainement pour de nouvelles aventures, je ne sais pas trop quand, d'ici là...

Portez-vous bien 🙂.