Einführung
Heute können Entwickler viele Abstraktionsschichten verwenden, um ihre Webanwendungen zu erstellen. Anstatt direkt mit den APIs der unteren Ebene zu interagieren, die die Webplattform bietet, nutzen viele Entwickler Frameworks, Build-Tools und Compiler, um ihre Anwendungen aus einer höheren Perspektive zu erstellen.
Komponenten, die auf dem Angular-Framework basieren, werden beispielsweise in TypeScript mit HTML-Vorlagen erstellt. Im Hintergrund kompilieren die Angular-Befehlszeile und webpack alles in JavaScript und in ein sogenanntes Bundle, das dann an den Browser gesendet wird.
Wenn Sie Webanwendungen in DevTools debuggen oder profilieren, sehen Sie derzeit diese kompilierte Version Ihres Codes anstelle des von Ihnen geschriebenen Codes. Als Autor möchten Sie das jedoch nicht:
- Sie möchten nicht den minimierten JavaScript-Code debuggen, sondern den ursprünglichen JavaScript-Code.
- Wenn Sie TypeScript verwenden, möchten Sie nicht JavaScript-Fehler beheben, sondern Ihren ursprünglichen TypeScript-Code debuggen.
- Wenn Sie templating wie mit Angular, Lit oder JSX verwenden, möchten Sie nicht immer das resultierende DOM debuggen. Möglicherweise möchten Sie die Komponenten selbst beheben.
Im Allgemeinen sollten Sie Ihren eigenen Code so debuggen, wie Sie ihn geschrieben haben.
Quellkarten schließen diese Lücke bereits teilweise, aber die Chrome-Entwicklertools und das gesamte System können in diesem Bereich noch mehr leisten.
Sehen wir uns das genauer an!
Erstellter und bereitgestellter Code
Wenn Sie derzeit im Bereich Quellen in der Dateistruktur den Inhalt des kompilierten – und oft minimierten – Bundles sehen, Das sind die tatsächlichen Dateien, die der Browser herunterlädt und ausführt. In den Entwicklertools wird dies als Bereitgestellter Code bezeichnet.
Dies ist nicht sehr praktisch und oft schwer zu verstehen. Als Autor möchten Sie den von Ihnen geschriebenen Code sehen und debuggen, nicht den bereitgestellten Code.
Stattdessen können Sie jetzt den vom Nutzer erstellten Code im Stammbaum anzeigen lassen. Dadurch ähnelt der Verzweigungsbaum den Quelldateien, die Sie in Ihrer IDE sehen. Diese Dateien sind jetzt vom bereitgestellten Code getrennt.
Wenn Sie diese Option in den Chrome-Entwicklertools aktivieren möchten, klicken Sie auf Einstellungen > Tests und setzen Sie ein Häkchen bei Quellen in Verzweigungen für erstellte und bereitgestellte Seiten gruppieren.
„Nur mein Code“
Wenn Sie Abhängigkeiten verwenden oder auf einem Framework aufbauen, können die Drittanbieterdateien ein Hindernis darstellen. In den meisten Fällen möchten Sie nur Ihren Code sehen, nicht den einer Drittanbieterbibliothek, die im Ordner node_modules versteckt ist.
Daher ist in den DevTools standardmäßig eine zusätzliche Einstellung aktiviert: Bekannte Drittanbieterskripts automatisch der Ignorieren-Liste hinzufügen. Sie finden sie unter DevTools > Einstellungen > Ignorierliste.
Wenn diese Einstellung aktiviert ist, werden in den DevTools alle Dateien oder Ordner ausgeblendet, die von einem Framework oder Build-Tool als zu ignorieren gekennzeichnet wurden.
Seit Angular v14.1.0 sind die Inhalte der Ordner node_modules und webpack entsprechend gekennzeichnet. Daher werden diese Ordner, die darin enthaltenen Dateien und andere Artefakte von Drittanbietern an verschiedenen Stellen in den Entwicklertools nicht angezeigt.
Als Autor müssen Sie nichts weiter tun, um dieses neue Verhalten zu aktivieren. Die Implementierung dieser Änderung obliegt dem Framework.
Ignorierter Code in Stacktraces
Dateien, die auf der Ignorieren-Liste nicht mehr angezeigt werden, befinden sich in Stacktraces. Als Entwickler sehen Sie jetzt mehr relevante Stack-Traces.
Wenn Sie alle Aufrufframes des Stack-Traces sehen möchten, können Sie jederzeit auf den Link Weitere Frames anzeigen klicken.
Gleiches gilt für die Aufrufstacks, die Sie beim Debuggen und Schritt-für-Schritt-Ausführen des Codes sehen. Wenn Frameworks oder Bundler DevTools über Drittanbieter-Scripts informieren, werden in DevTools automatisch alle irrelevanten Aufrufframes ausgeblendet und beim Schritt-für-Schritt-Debugging wird Code, der auf der Ignorierliste steht, übersprungen.
Code auf der Ignorieren-Liste im Dateibaum
Wenn Sie die Dateien und Ordner in der Ignorierliste im Dateibaum Autorisierter Code im Bereich Quellen ausblenden möchten, aktivieren Sie in den DevTools unter Einstellungen > Experimente die Option Code in der Ignorierliste in der Strukturansicht der Quellen ausblenden.
Im Beispiel-Angular-Projekt sind die Ordner node_modules und webpack jetzt ausgeblendet.
Ignorierte Codes im Menü „Schnell öffnen“
Code in der Ignorierliste wird nicht nur im Dateibaum ausgeblendet, sondern auch im Menü „Schnell öffnen“ (Strg + P (Linux/Windows) oder Befehl + P (Mac)).
Weitere Verbesserungen an Stack-Traces
Wir haben bereits relevante Stack-Traces behandelt. In den Chrome-Entwicklertools gibt es aber noch weitere Verbesserungen.
Verknüpfte Stack-Traces
Wenn einige Vorgänge asynchron ausgeführt werden, geben die Stack-Traces in den DevTools derzeit nur einen Teil der Informationen preis.
Hier ist beispielsweise ein sehr einfacher Zeitplaner in einer hypothetischen framework.js-Datei:
function makeScheduler() {
const tasks = [];
return {
schedule(f) {
tasks.push({ f });
},
work() {
while (tasks.length) {
const { f } = tasks.shift();
f();
}
},
};
}
const scheduler = makeScheduler();
function loop() {
scheduler.work();
requestAnimationFrame(loop);
};
loop();
… und wie ein Entwickler sie in seinem eigenen Code in einer example.js-Datei verwenden könnte:
function someTask() {
console.trace("done!");
}
function businessLogic() {
scheduler.schedule(someTask);
}
businessLogic();
Wenn Sie in der Methode someTask einen Haltepunkt einfügen oder den in der Konsole gedruckten Trace prüfen, wird der businessLogic()-Aufruf, der die „Ursache“ dieses Vorgangs war, nicht erwähnt.
Stattdessen sehen Sie nur die Framework-Planungslogik, die zur Ausführung der Aufgaben geführt hat, und keine Navigationspfade im Stacktrace, mit denen Sie die kausalen Zusammenhänge zwischen Ereignissen, die zu dieser Aufgabe führen, herausfinden können.
Dank einer neuen Funktion namens „Async Stack Tagging“ ist es jedoch möglich, die gesamte Geschichte zu erzählen, indem beide Teile des asynchronen Codes miteinander verknüpft werden.
Die Async Stack Tagging API führt eine neue console-Methode namens console.createTask() ein. Die API-Signatur sieht so aus:
interface Console {
createTask(name: string): Task;
}
interface Task {
run<T>(f: () => T): T;
}
Der console.createTask()-Aufruf gibt eine Task-Instanz zurück, mit der Sie später den Inhalt der Aufgabe f ausführen können.
// Task Creation
const task = console.createTask(name);
// Task Execution
task.run(f);
Die Aufgabe bildet die Verknüpfung zwischen dem Kontext, in dem sie erstellt wurde, und dem Kontext der asynchronen Funktion, die ausgeführt wird.
Angewandt auf die makeScheduler-Funktion oben sieht der Code so aus:
function makeScheduler() {
const tasks = [];
return {
schedule(f) {
const task = console.createTask(f.name);
tasks.push({ task, f });
},
work() {
while (tasks.length) {
const { task, f } = tasks.shift();
task.run(f); // instead of f();
}
},
};
}
Dadurch können in den Chrome-Entwicklertools jetzt bessere Stack-Traces angezeigt werden.
Sie sehen, dass businessLogic() jetzt im Stacktrace enthalten ist. Außerdem hat die Aufgabe einen bekannten Namen, someTask, anstelle des generischen requestAnimationFrame wie zuvor.
Frames für freundliche Anrufe
Frameworks generieren beim Erstellen eines Projekts häufig Code aus allen Arten von Vorlagensprachen, z. B. Angular- oder JSX-Vorlagen, die HTML-ähnlichen Code in einfachen JavaScript-Code umwandeln, der schließlich im Browser ausgeführt wird. Manchmal erhalten diese Arten von generierten Funktionen Namen, die nicht sehr ansprechend sind – entweder Namen mit einzelnen Buchstaben, nachdem sie reduziert wurden, oder unklare oder unbekannte Namen, selbst wenn dies nicht der Fall ist.
Im Beispielprojekt ist das AppComponent_Template_app_button_handleClick_1_listener, das im Stack-Trace zu sehen ist.
In den Chrome-Entwicklertools können Sie diese Funktionen jetzt über Quellkarten umbenennen. Wenn eine Quellkarte einen Namenseintrag für den Beginn eines Funktionsbereichs enthält, sollte der Aufrufframe diesen Namen im Stack-Trace anzeigen.
Als Autor müssen Sie nichts weiter tun, um dieses neue Verhalten zu aktivieren. Es liegt an den Rahmenbedingungen, diese Änderung umzusetzen.
Zukunftspläne
Dank der in diesem Beitrag beschriebenen Ergänzungen können Sie die Chrome-Entwicklertools noch effektiver für das Debuggen verwenden. Es gibt weitere Bereiche, die das Team gerne untersuchen würde. Insbesondere, wie die Profilerstellung in den Entwicklertools verbessert werden kann.
Das Chrome DevTools-Team empfiehlt Framework-Entwicklern, diese neuen Funktionen zu nutzen. In der Fallstudie: Better Angular Debugging with DevTools erfahren Sie, wie Sie dies implementieren können.