Le besoin : éviter une popup différente pour chaque fonctionnalité

Au début d’un projet, créer une popup directement dans la page semble être la solution la plus simple. On ajoute un bloc HTML, quelques règles CSS et un événement JavaScript pour l’ouvrir ou la fermer. Tant qu’il n’existe qu’une seule fenêtre, cette méthode fonctionne parfaitement. Le problème apparaît lorsqu’une deuxième popup doit être ajoutée, puis une troisième, puis une quatrième. Chaque fonctionnalité apporte alors son propre code et entraîne rapidement une duplication de code.

Les différences s’accumulent ensuite sans que l’on s’en rende compte. Une fenêtre se ferme avec la touche Échap, une autre uniquement avec une croix, une troisième au clic sur l’arrière-plan. Chaque popup finit par avoir son propre fonctionnement, ses propres événements et ses propres styles. Plus le projet grandit, plus ces variantes deviennent difficiles à relire et à maintenir. Le véritable besoin n’est donc pas seulement de créer une fenêtre, mais de centraliser la logique utilisée par toutes les popups.

Le principe : décrire la popup au lieu de la reconstruire

Le changement d’approche consiste à ne plus écrire une nouvelle structure HTML pour chaque fenêtre. L’application fournit uniquement les informations nécessaires : un titre, un contenu, une largeur éventuelle et une liste de boutons. Le composant se charge ensuite de construire la popup à partir de ces données. La partie métier ne manipule plus directement son HTML, elle décrit ce qu’elle veut afficher. Cette configuration devient le point de départ commun à toutes les fenêtres.

Une confirmation de suppression et un formulaire de paramètres peuvent ainsi utiliser exactement le même mécanisme. Leur contenu change, mais leur création, leur affichage et leur fermeture reposent sur une même règle. Cette organisation réduit les répétitions et rend les comportements cohérents dans toute l’application. Une modification générale peut être effectuée à un seul endroit au lieu d’être répétée dans chaque fonctionnalité. Pour ouvrir une fenêtre, l’application appelle simplement le PopupManager.

L’organisation : une classe Popup et un gestionnaire central

La classe Popup représente une seule fenêtre ouverte à l’écran. Elle connaît son titre, son contenu, ses boutons et ses options de fermeture. Elle construit les éléments HTML nécessaires, branche les événements puis ajoute la fenêtre dans la page. Lorsqu’elle se ferme, elle retire également ses événements et supprime proprement son interface. Sa responsabilité reste donc claire : gérer sa propre existence.

La classe Popup ne décide toutefois jamais quand une nouvelle fenêtre doit être créée. Cette décision appartient au PopupManager, qui reçoit une configuration et instancie la popup correspondante. Il conserve aussi la liste des fenêtres actives afin de connaître leur ordre d’ouverture. Il peut ainsi fermer la dernière popup, fermer toutes les fenêtres ou mettre à jour leur empilement. Cette séparation permet de distinguer la fenêtre de la gestion globale des fenêtres.

Les actions : associer chaque bouton à un comportement clair

Une popup est rarement limitée à un simple message. Elle contient généralement des boutons pour valider, annuler, supprimer, enregistrer ou fermer. Dans cette ressource, chaque bouton est décrit par un libellé, une classe CSS éventuelle et une fonction à exécuter. La popup crée automatiquement le bouton puis déclenche la fonction au clic. Chaque action reste ainsi définie avec son bouton.

La fonction appelée reçoit directement l’instance de la fenêtre. Elle peut donc fermer la popup sans rechercher un élément dans toute la page. La logique applicative reste dans le fichier de démonstration, tandis que le composant conserve un fonctionnement générique. Le PopupManager ne sait pas ce qu’est une suppression, un enregistrement ou une confirmation. Il fournit uniquement un cadre commun dans lequel l’application définit ses propres actions.

La fermeture : conserver des règles cohérentes dans toute l’application

Une fenêtre modale doit pouvoir être fermée de manière prévisible. La ressource propose les trois comportements les plus courants : le bouton de fermeture, la touche Échap et le clic sur l’arrière-plan. Les deux derniers peuvent être désactivés lorsqu’une décision doit obligatoirement passer par un bouton. Toutes les fenêtres partagent ainsi une même logique de fermeture. Il n’est plus nécessaire de réécrire les mêmes événements pour chaque popup.

La fermeture retire d’abord la classe utilisée pour l’animation, puis supprime la fenêtre du document une fois la transition terminée. Les événements clavier sont également retirés afin qu’ils ne restent pas actifs après sa disparition. Le gestionnaire est ensuite informé pour mettre à jour sa liste de fenêtres ouvertes. Le composant ne se contente donc pas de disparaître visuellement, il sait aussi se nettoyer correctement. Cette étape permet de l’utiliser plusieurs fois sans accumuler des événements ou des références inutiles.

L’empilement : gérer plusieurs fenêtres sans perdre le contrôle

Dans certaines applications, une popup peut en ouvrir une autre. Ce cas peut apparaître lorsqu’un formulaire déclenche une confirmation, affiche un aperçu ou demande une information complémentaire. Le gestionnaire conserve donc les fenêtres dans leur ordre d’ouverture. Chaque nouvelle popup reçoit un niveau d’affichage supérieur à la précédente. La dernière ouverte reste ainsi au-dessus des autres.

Cette dernière fenêtre devient également la popup prioritaire pour les interactions au clavier. Un appui sur Échap ne doit fermer que la fenêtre active, et non toutes celles qui se trouvent derrière. La classe Popup vérifie donc auprès du gestionnaire qu’elle est bien la dernière ouverte avant de réagir. Cette règle évite qu’une seule action provoque plusieurs fermetures successives. Le système conserve ainsi un ordre d’affichage et un ordre d’interaction cohérents.

Le résultat : un composant réutilisable et facile à faire évoluer

Le principal intérêt de ce Popup Manager n’est pas son apparence ou son animation. Il fournit surtout une structure commune pour toutes les fenêtres de l’application. Ajouter une popup consiste désormais à décrire son contenu et ses actions, sans recréer son fonctionnement complet. Une modification du style, de l’accessibilité ou des règles de fermeture profite immédiatement à tous les usages. Le code métier reste concentré sur ce qu’il doit réellement accomplir.

Cette organisation convient aussi bien à un petit site qu’à une application plus importante. Elle peut ensuite accueillir des formulaires, du contenu chargé dynamiquement, des validations ou des traitements asynchrones. L’essentiel reste pourtant très simple : une classe gère la fenêtre et un gestionnaire centralise les ouvertures. Chaque partie possède une responsabilité claire et l’application utilise un point d’entrée unique. C’est cette simplicité qui rend le composant facile à comprendre, à réutiliser et à faire évoluer.