Le besoin : déplacer des éléments sans multiplier les cas particuliers

Une première version d’un glisser-déposer peut être écrite très rapidement. On écoute le déplacement de la souris, on modifie la position d’un élément, puis on le replace lorsque le bouton est relâché. Cette approche fonctionne pour une démonstration, mais elle devient vite fragile dès que l’interface doit accepter plusieurs cartes, une zone de dépôt ou un changement d’ordre. Le code commence alors à mélanger la gestion du pointeur, le déplacement visuel, la recherche de la cible et la mise à jour des données. Chaque nouvelle fonctionnalité ajoute une condition supplémentaire.

Le tactile complique encore le problème si la logique repose uniquement sur les événements de souris. Il faut alors maintenir deux implémentations différentes qui réalisent pourtant le même geste. Les Pointer Events permettent au contraire d’utiliser un seul mécanisme pour la souris, le stylet et les écrans tactiles. Le navigateur fournit un identifiant de pointeur et des coordonnées cohérentes, ce qui simplifie fortement la ressource. Le même code peut ainsi fonctionner sur ordinateur, tablette et téléphone.

Le principe : séparer le geste utilisateur de la mise à jour de la liste

Le déplacement visuel n’est qu’une partie du problème. L’application doit aussi savoir quel élément est manipulé, où il se trouve et dans quel ordre il doit être replacé. La ressource sépare donc le geste du résultat : le pointeur indique une intention, puis la liste applique cette intention à ses données. Cette distinction évite de dépendre uniquement de la position temporaire des éléments dans la page. Le glisser-déposer reste alors compréhensible même lorsque la présentation évolue.

Au début du geste, la carte active est identifiée et une copie visuelle suit le pointeur. L’élément original conserve sa place afin de ne pas faire sauter brutalement toute la mise en page. Pendant le déplacement, le code repère la carte située sous le pointeur et affiche un emplacement de prévisualisation. Au relâchement, la carte est déplacée dans le DOM à la position calculée. Le résultat est immédiatement visible et l’ordre peut être relu ou enregistré.

Le pointeur : conserver des coordonnées fiables du début à la fin

Un glisser-déposer doit rester stable même lorsque le pointeur sort légèrement de la carte. La méthode setPointerCapture() permet de continuer à recevoir les événements liés au geste en cours. Elle doit cependant être appliquée uniquement à l’élément manipulé, et non à toute la démonstration. Une capture trop large intercepterait les clics destinés aux boutons ou aux autres composants de la page. La ressource limite donc volontairement cette capture à la carte active.

Les coordonnées utilisées sont celles de la fenêtre avec clientX et clientY. Elles servent à positionner la copie visuelle et à rechercher l’élément situé sous le pointeur avec document.elementFromPoint(). Cette méthode évite de recalculer manuellement la position de chaque carte. Elle permet également de savoir si le pointeur se trouve au-dessus de la liste ou de la zone de dépôt. Le code reste court tout en conservant un comportement précis.

La zone de dépôt : fournir un retour visuel avant de modifier le contenu

Le lecteur doit comprendre immédiatement où la carte sera déposée. Une zone qui accepte un élément change donc d’apparence lorsque le pointeur la survole. Ce retour visuel ne modifie pas encore les données : il prépare simplement l’utilisateur au résultat de son geste. La carte n’est réellement déplacée qu’au moment du relâchement. Cette distinction évite les déplacements accidentels et rend l’interface plus prévisible.

La démonstration utilise deux listes. La première contient les cartes disponibles et la seconde représente la sélection ou l’ordre final. Une carte peut passer d’une liste à l’autre, puis être réorganisée à l’intérieur de la même liste. Le compteur est recalculé après chaque opération et la dernière action est affichée. On visualise ainsi la différence entre le déplacement temporaire et la mise à jour définitive de l’état.

La réorganisation : calculer une position d’insertion plutôt qu’une position absolue

Pour réordonner une liste, il n’est pas nécessaire d’enregistrer les coordonnées finales de chaque carte. Il suffit de déterminer avant ou après quel élément la carte active doit être insérée. La ressource compare la position verticale du pointeur avec le centre des cartes visibles. Le premier élément dont le centre se trouve sous le pointeur devient la référence d’insertion. En l’absence de référence, la carte est ajoutée à la fin.

Cette approche résiste mieux aux changements de taille et au responsive qu’un système fondé sur des coordonnées fixes. Les cartes peuvent devenir plus larges, passer sur plusieurs lignes ou changer de contenu sans modifier l’algorithme principal. L’ordre réel reste celui du DOM, ce qui permet ensuite de le convertir simplement en tableau JavaScript. Le même principe peut être utilisé pour un menu administrable, une liste de tâches ou un formulaire dont les sections sont réorganisables.

Les comportements parasites : protéger le geste de déplacement sans bloquer le reste

Lorsqu’un élément est déplacé, le navigateur peut tenter de sélectionner du texte, de faire glisser une image native ou de faire défiler la page. Ces comportements sont utiles dans d’autres contextes, mais ils nuisent ici à la précision du geste. La classe CSS touch-action: none est donc appliquée uniquement aux poignées de déplacement. Le reste de la page conserve son fonctionnement normal, notamment le défilement tactile et les clics sur les boutons.

La prévention des événements est également limitée au geste actif. Le code ne bloque pas globalement les événements de pointeur et ne capture jamais tout le conteneur de la ressource. Cette règle est importante dans une page WordPress qui peut contenir d’autres composants interactifs. Un composant bien isolé doit gérer ce qui lui appartient sans modifier le comportement des éléments voisins. C’est ce qui permet à la démonstration de rester réutilisable.

Le résultat : une base simple à lire et facile à adapter

La ressource fournit un glisser-déposer complet avec souris, tactile, réorganisation, zone de dépôt, compteur et réinitialisation. Le code reste volontairement court et chaque méthode possède une responsabilité claire. Il peut être repris tel quel pour construire un Kanban, un éditeur de blocs, une liste de favoris ou un outil de classement. Les données affichées ne sont qu’un exemple : le mécanisme ne dépend ni du contenu des cartes ni de leur apparence.

Le point essentiel n’est pas l’animation de la carte, mais la manière dont le geste est transformé en une modification fiable de l’ordre. En séparant l’écoute du pointeur, la prévisualisation et l’application du résultat, on obtient un composant plus simple à tester et à faire évoluer. Le même raisonnement peut ensuite être appliqué à des interfaces beaucoup plus complexes. Le glisser-déposer devient alors une brique de l’application, et non une suite d’événements dispersés.