Driver.js

Un voile sombre percé autour de l'élément à montrer

Driver.js assombrit la page web, laisse l'élément visé hors du voile et ouvre à côté de lui un popover avec un titre, un texte et des boutons. La méthode highlight() le fait pour un seul élément, drive() enchaîne une liste d'étapes en tour produit. Deux modules optionnels reprennent ce popover : les hints, des balises qui pulsent sur la page, et une checklist de démarrage. La bibliothèque est écrite en TypeScript et n'a aucune dépendance.

Tours interactifs, balises pulsantes et checklist de démarrage

• Une étape peut attendre un geste de l'utilisateur. Avec advanceOnClick, un clic sur l'élément mis en avant fait passer à la suite ; waitForElement laisse jusqu'à N millisecondes à un élément rendu à la demande pour apparaître, par exemple dans une modale ouverte à l'étape précédente.
• Une étape dont l'élément manque dans le DOM peut être sautée avec skipMissingElement, au lieu de retomber sur un popover centré.
• Les hooks de fin de tour reçoivent un reason, qui distingue le tour mené au bout, la fermeture par le bouton, par Échap ou par un clic sur le voile, le remplacement par une autre instance et l'arrêt commandé par le code.
• Les flèches du clavier et Échap pilotent le tour, sauf quand le bouton correspondant est masqué ou désactivé. Les libellés des boutons et l'aria-label du bouton de fermeture (closeBtnLabel) se règlent, pour un tour traduit.
• Les hints s'ouvrent au clic, dans n'importe quel ordre, sans voile par défaut, et la page reste utilisable. Hints et tours cohabitent sans code de liaison : pendant un tour, les balises se retirent, puis reviennent à la fin.
• La checklist est un widget posé dans un coin de l'écran. Chaque item lance un tour, ouvre un lien, exécute une fonction, ou se coche dès que sa fonction completeWhen renvoie true.
• Hints et checklist s'importent depuis driver.js/hints et driver.js/checklist, chacun avec sa feuille de style. Un site qui s'en tient aux tours ne les charge pas.

Étapes dans le code, progression et mesures côté application

Les tours s'écrivent en JavaScript. Chaque étape est un objet qui désigne son élément par un sélecteur CSS, et la documentation ne décrit pas d'autre moyen d'en créer. La bibliothèque s'adresse donc à l'équipe qui tient le code du front. Usertour, une plateforme qui s'auto-héberge avec Docker, garde au contraire ses parcours dans son propre compte, avec l'historique des modifications et le taux de complétion de chaque parcours.

Rien n'est conservé d'une visite à l'autre. Un hint écarté par l'utilisateur ne le reste que le temps de la session, et la checklist ne stocke rien. Sa progression entre par l'option completed et ressort par onProgress : à l'application de la ranger dans le localStorage, dans son API ou sur la fiche de l'utilisateur. Les événements de la checklist arrivent de la même façon dans onEvent, prêts à partir vers l'outil d'analytics de l'application.

Le README refuse l'étiquette de bibliothèque de tours de plus. À la question « encore une bibliothèque de tours ? », il répond non : le tour n'est qu'un usage d'un voile posé sur la page, comme l'aide contextuelle pendant la saisie d'un formulaire, l'effet « éteindre la lumière » des lecteurs vidéo ou une simple modale. Il annonce aussi environ 5 ko gzippés, contre plus de 12 ko pour d'autres bibliothèques qu'il ne nomme pas.

La 1.10.2, publiée le 18 octobre 2026, est la huitième version depuis juin. Rien n'était sorti entre la 1.4.0 de novembre 2025 et la 1.5.0 du 23 juin 2026. Les hints sont arrivés avec la 1.8.0 en juillet, les checklists avec la 1.10.0 le 15 octobre. Une version mineure peut casser l'existant : la 1.6.0, marquée « Breaking » dans ses notes, ne stylise plus les boutons ajoutés au pied du popover. Or le lien CDN de la documentation d'installation pointe sur @latest, qui suit chaque version, ruptures comprises.