En tant que développeurs Web, nous passons beaucoup de temps à créer notre code dans un environnement d’édition. Nous passons ensuite au navigateur pour utiliser les outils de développement intégrés pour déboguer et modifier l’interface utilisateur du produit. Le problème avec cela est que les résultats des ajustements et du débogage ne sont pas reflétés dans le code source. Dans Microsoft Edge, nous travaillons actuellement sur quelques solutions ouvertes à la discussion, et nous aimerions vos commentaires sur eux
Si vous préférez regarder une vidéo au lieu de lire, voici une introduction de trois minutes :
Le problème actuel avec les ajustements et les modifications dans les outils de développement
Aujourd’hui, les DevTools de navigateur fournissent des outils visuels hautement sophistiqués qui vous enseignent-par exemple-la syntaxe CSS pendant que vous les utilisez. Ces outils changent les choses de manière visuelle. Par exemple, vous pouvez cliquer sur l’icône”Flexbox”à côté de n’importe quelle propriété CSS flexbox et vous obtenez une fenêtre contextuelle vous donnant un aperçu du résultat de ce changement de style.
Il s’agit d’une excellente expérience de débogage et vous évite d’avoir à rechercher la syntaxe CSS tout le temps. Cependant, il y a une déconnexion, car le code affiché dans ces workflows de débogage n’est pas ce que vous avez écrit dans votre éditeur de code.
L’éditeur de styles fonctionne en n’affichant qu’une vue partielle du code pour l’actuel élément sélectionné dans le navigateur. Vous ne savez pas où et comment ce code s’intègre dans le reste de votre CSS sur votre page Web. Bien que vous puissiez faire défiler pour afficher le reste du code, ne serait-il pas préférable de voir également l’original Fichier CSS ?
Vous pouvez y accéder en cliquant sur les liens vers le fichier CSS lui-même, ce qui vous amène à l’outil Sources et loin de l’éditeur de styles.
Celui-ci est un éditeur intégrés dans les outils de développement du navigateur qui étaient astucieux à leur sortie mais qui ne brillent pas par rapport à ce que nous attendons d’un éditeur de nos jours. À moins que vous ne détachiez les outils et que vous ne les utilisiez dans votre propre fenêtre, vous ne disposez pas non plus d’une surface d’écran suffisante pour une expérience d’édition pratique.
Que vous utilisiez les outils visuels pour peaufiner votre CSS, ou l’éditeur de sources, un problème demeure : une fois que vous avez beaucoup changé des choses et que vous êtes arrivé au résultat souhaité, comment réintégrez-vous ces modifications dans votre code source ?
Saviez-vous qu’il existe un outil de modification ?
Les outils de développement de navigateur ont une fonctionnalité qui aide à cela appelée Modifications qui n’est pas très utilisée et qui est largement inconnue. Vous pouvez y accéder à partir du menu de commande ou du menu contextuel et il vous montre une vue diff de tous les fichiers que vous avez modifiés dans cette session. Vous pouvez utiliser cet outil pour copier et coller les modifications dans vos fichiers source.
Firefox utilise une approche légèrement différente d’un outil de modifications qui se met à jour en direct avec les modifications que vous apportez. Il crée également un fichier CSS que vous pouvez copier et coller avec des commentaires expliquant dans quels fichiers coller ces modifications et ce qui a été supprimé ou ajouté.
Bien que ce soit un bon pas dans la bonne direction, il faut une étape supplémentaire pour copier et coller le code dans votre éditeur.
Un flux d’espace de travail amélioré incluant Visual Studio CodeLes espaces de travail dans Chromium Developer Tools existent depuis longtemps mais ne sont pas très utilisés. C’est pourquoi nous voulions rendre plus évident que vous pouvez avoir une synchronisation en direct des modifications entre les DevTools du navigateur et un éditeur de code. Nous avons également réalisé que l’éditeur de l’outil Sources n’est pas ce que les gens veulent utiliser.
Et si vous pouviez avoir la commodité de l’éditeur que vous utilisez déjà et les avantages des modifications en direct des fichiers des espaces de travail ?
À partir de la version 96 de Microsoft Edge, vous pouvez trouver une nouvelle expérience dans DevTools appelée”Ouvrir les fichiers source dans Visual Studio Code“.
Une fois que vous avez activé celui-ci et redémarré les outils de développement, accédez à un fichier sur votre disque dur ou à une adresse de serveur local comme localhost ou 127.0.0.1 vous donnera une invite vous demandant d’identifier le dossier racine de ce fichier. Vous pouvez également désactiver une session ou ne jamais voir cette option a gain.
Une fois vous choisissez un dossier, le navigateur vous demande la permission d’accéder à ce dossier-un peu comme vous deviez le faire lorsque vous utilisiez les espaces de travail dans l’outil Sources.
Lorsque vous effectuez maintenant une modification dans le volet Styles, le fichier change sur le disque. La différence est que lorsque vous avez Visual Studio Code comme éditeur sur l’ordinateur, cliquer sur les liens vers les fichiers les ouvrira dans cet éditeur au lieu de celui de l’outil Sources. Vous restez dans l’environnement auquel vous êtes habitué avec toutes les personnalisations et extensions que vous y avez ajoutées.
C’est formidable car vos modifications CSS sont maintenant permanentes. Le problème est cependant qu’ils peuvent être trop intrusifs. Tout changement dans l’outil Styles, comme la modification d’une taille d’une unité, entraînera la modification du fichier sur votre disque dur. Si vous utilisez une solution de serveur de rechargement en direct ou même des scripts qui surveillent un dossier et déclenchent un processus de construction, cela peut rapidement devenir désordonné.
Édition miroir CSS
Dans la dernière version du Edge DevTools for Visual Studio Code extension nous avons introduit une autre façon de fermer la boucle de création/débogage appelée”CSS Mirror Editing”. Si vous le souhaitez, vous pouvez regarder cette introduction vidéo de 40 secondes.
Si vous activez cette fonctionnalité, les modifications apportées dans l’outil Styles affectent également le code source, mais le fichier reste inchangé jusqu’à ce que vous l’enregistriez dans Visual Studio Code. Vous avez l’avantage de ne pas perdre vos modifications et vous gardez un contrôle total sur les fichiers sur le disque dur.
Si vous utilisez le contrôle de version, vous pouvez voir toutes les modifications que vous avez apportées une vue diff une fois que vous avez enregistré le fichier. Cela vous donne toute la commodité du flux de travail des espaces de travail avec moins de modifications des fichiers.
Que devrions-nous faire pour améliorer cette expérience ?
Il semble que nous ayons tous les bons composants dans endroit pour offrir aux développeurs une expérience de création et de débogage de bout en bout. Nous aimerions savoir ce que vous pensez de ces approches et laquelle vous préférez.
Si vous avez des commentaires, veuillez contacter l’équipe Edge DevTools sur Twitter à @EdgeDevTools, commentez ce problème sur GitHub à propos de l’édition miroir CSS ou utilisez l’outil Feedback intégré aux DevTools dans le navigateur.
– Chris Heilmann, responsable de programme principal, Microsoft Edge
