Als webontwikkelaars besteden we veel tijd aan het schrijven van onze code in een bewerkingsomgeving. Vervolgens gaan we naar de browser om de ingebouwde ontwikkelaarstools te gebruiken om de gebruikersinterface van het product te debuggen en aan te passen. Het probleem hiermee is dat de resultaten van het tweaken en debuggen niet worden weerspiegeld in de broncode. In Microsoft Edge werken we momenteel aan een aantal oplossingen die open staan voor discussie, en die zouden uw feedback hierover
Als u liever een video bekijkt in plaats van leest, hier is een introductie van drie minuten:
Het huidige probleem met tweaks en veranderingen in Developer Tools
Tegenwoordig bieden browser DevTools zeer geavanceerde visuele hulpmiddelen die u bijvoorbeeld de CSS-syntaxis leren terwijl u ze gebruikt. Deze tools veranderen dingen op een visuele manier. U kunt bijvoorbeeld op het”Flexbox”-pictogram naast een CSS-flexbox-eigenschap klikken en u krijgt een pop-up met een voorbeeld van het resultaat van die stijlwijziging.
Dit is een uitstekende foutopsporingservaring en voorkomt dat u de hele tijd de CSS-syntaxis moet opzoeken Er is echter een verbroken verbinding, aangezien de code die wordt weergegeven in deze foutopsporingsworkflows niet is wat u in uw code-editor hebt geschreven.
De Styles-editor werkt door slechts een gedeeltelijke weergave van de code voor de huidige element geselecteerd in de browser. U weet niet waar en hoe die code in de rest van uw CSS op uw webpagina past. Hoewel u kunt scrollen om de rest van de code te bekijken, zou het niet beter zijn om ook het origineel te zien CSS-bestand?
Je kunt die openen door op de links naar het CSS-bestand zelf te klikken, waardoor je naar de Sources Tool gaat en weg van de Styles-editor.
Dit is een editor ingebed in de browserontwikkelaarstools die handig waren toen ze uitkwamen, maar niet schitteren in vergelijking met wat we tegenwoordig van een editor verwachten. Tenzij je de tools loskoppelt en ze in een eigen venster gebruikt, heb je ook niet genoeg schermruimte voor een gemakkelijke bewerkingservaring.
Of je nu de visuele tools gebruikt om je CSS aan te passen, of de Sources-editor, er blijft één probleem: als je eenmaal veel hebt veranderd van dingen en je bent tot het gewenste resultaat gekomen, hoe krijg je deze wijzigingen terug in je broncode?
Wist je dat er een tool voor wijzigingen is?
Browser Developer Tools hebben een functie die hierbij helpt, genaamd Changes, wordt niet veel gebruikt en is grotendeels onbekend. U kunt het openen vanuit het commandomenu of het contextmenu en het toont u een diff-weergave van alle bestanden die u in deze sessie hebt gewijzigd. U kunt deze tool gebruiken om de wijzigingen te kopiëren en terug te plakken in uw bronbestanden.
Firefox gebruikt een iets andere benadering van een wijzigingstool die live bijwerkt met wijzigingen die u aanbrengt. Er wordt ook een CSS-bestand gemaakt dat u kunt kopiëren en plakken, met opmerkingen waarin wordt uitgelegd in welke bestanden u deze wijzigingen moet plakken en wat er is verwijderd of toegevoegd.
Hoewel dit een goede stap in de goede richting is, vereist het een extra stap om de code te kopiëren en plakken terug naar uw editor.
Een verbeterde Workspace-stroom inclusief Visual Studio CodeWerkruimten in Chromium Developer Tools bestaan al heel lang, maar zien niet zoveel nut. Daarom wilden we het duidelijker maken dat u wijzigingen live kunt synchroniseren tussen browser DevTools en een code-editor. We realiseerden ons ook dat de editor in de Sources-tool niet is wat mensen willen gebruiken.
Wat als je het gemak zou hebben van de editor die je al gebruikt en de voordelen van live wijzigingen in bestanden van Workspaces?
Vanaf versie 96 van Microsoft Edge kun je een nieuw experiment vinden in DevTools genaamd “Open source-bestanden in Visual Studio Code“.
Als je deze eenmaal hebt ingeschakeld en de ontwikkelaarstools opnieuw hebt opgestart, ga je naar een bestand op je harde schijf of een lokaal serveradres zoals localhost of 127.0.0.1 zal u een prompt geven waarin u wordt gevraagd om de hoofdmap van dit bestand te identificeren. U kunt zich ook afmelden voor een sessie of deze optie nooit zien a winst.
Eenmaal je kiest een map, de browser vraagt je om toestemming om toegang te krijgen tot die map-net zoals je moest doen bij het gebruik van Workspaces in de Sources-tool.
Als u nu een wijziging aanbrengt in het deelvenster Stijlen, verandert het bestand op schijf. Het verschil is dat wanneer u Visual Studio Code als uw editor op de computer heeft, door op de koppelingen naar de bestanden te klikken, ze in deze editor worden geopend in plaats van die in de tool Bronnen. Je blijft in de omgeving die je gewend bent met alle aanpassingen en extensies die je eraan hebt toegevoegd.
Dit is geweldig omdat je CSS-wijzigingen nu permanent zijn. Het probleem is echter dat ze te opdringerig kunnen zijn. Elke wijziging in het gereedschap Stijlen, zoals het wijzigen van een grootte met één eenheid, zal ertoe leiden dat het bestand op uw harde schijf verandert. Als je een serveroplossing voor live herladen gebruikt of zelfs scripts die een map bekijken en een bouwproces activeren, kan dit snel rommelig worden.
CSS spiegelbewerkingen
In de nieuwste versie van de Edge DevTools for Visual Studio Code-extensie we hebben een andere manier geïntroduceerd om de authoring-/debugging-loop genaamd”CSS Mirror Editing”te sluiten. Als je wilt, kun je deze 40 seconden video-introductie bekijken.
Als u deze functie inschakelt, hebben wijzigingen die in het hulpmiddel Stijlen worden aangebracht ook invloed op de broncode, maar het bestand blijft ongewijzigd totdat u het opslaat in Visual Studio Code. U krijgt het voordeel dat uw wijzigingen niet verloren gaan en u behoudt de volledige controle over de bestanden op de harde schijf.
Als je versiebeheer gebruikt, kun je alle wijzigingen zien die je hebt gemaakt als een diff-weergave nadat u het bestand hebt opgeslagen. Dit geeft u al het gemak van de Workspaces-workflow met minder wijzigingen aan de bestanden.
Wat moeten we doen om deze ervaring te verbeteren?
Het lijkt erop dat we over alle juiste componenten beschikken plek om ontwikkelaars en end-to-end authoring-en debugging-ervaring te bieden. We willen graag weten wat u van deze benaderingen vindt en welke uw voorkeur heeft.
Als u feedback heeft, neem dan contact op met het Edge DevTools-team op Twitter via @EdgeDevTools, reageer op dit nummer op GitHub over CSS Mirror Editing of gebruik de Feedback-tool die in de DevTools in de browser is ingebouwd.
– Chris Heilmann, hoofdprogrammamanager, Microsoft Edge
