Einblicke in die Chrome Devtools

Als Frontend-Webentwickler sind die Devtools der Browser für die Meisten nicht aus dem Alltag wegzudenken. Sie werden stetig weiterentwickelt und bieten dem Entwickler eine Vielzahl an Funktionen zur Unterstützung bei der Fehlersuche oder um schnelleres Feedback zu erhalten. Ich möchte euch in diesem Blog einige davon vorstellen, die ich oft einsetze oder speziell erwähnenswert finde. Die Funktionen werden sich an den Google Chrome Devtools ausrichten, da ich damit die besten Erfahrungen gesammelt habe, jedoch bieten andere Browser (Firefox, Microsoft Edge, etc.) die gleichen oder mindestens ähnliche Funktionen.

Die Kapitel werden sich an den Tabs der Devtools orientieren, es werden aber nicht alle behandelt.

Elements

Der Elements-Tab kann helfen das gerenderte HTML und CSS zu inspizieren bzw. zu verändern um schnell und ohne Codeänderung kleinere Dinge auszuprobieren.

HTML

Im HTML-Teil hat es oft mehr als nur ein paar Elemente und es kann schwierig sein das richtige zu finden. Dabei hilft die Funktion im Tab-Header oben links:

Beim Hover über den Elementen werden gleich einige Details dazu angezeigt und beim Klicken auf das Element wird man zum HTML dazu geleitet.

Manchmal besteht der Wunsch, ohne Änderungen am Code schnell zu experimentieren, wie sich ein längerer Text oder eine andere Änderung im HTML auswirkt. Dies kann mithilfe der Funktion ‹Edit as HTML› direkt in den Devtools erreicht werden, welche es ermöglicht, das HTML direkt anzupassen.

Eine weitere Möglichkeit um mit dem Inhalt einer Seite etwas zu spielen ist der Design-Mode. Dieser erlaubt das Editieren von Text auf einer Seite direkt im Browserfenster und wird mit dem Command «document.designMode = ‹on'» in der Konsole aktiviert.

CSS

Im Elements-Tab auf der rechten Seite können auch CSS-Styles bearbeitet werden. Dabei werden die Styles jeweils für das ausgewählte HTML-Element auf der linken Seite angezeigt.

Durch den .cls-Toggle können neue Klassen einfach hinzugefügt oder entfernt werden. Im Bereich «element.style» können eigene Styles direkt auf dieses Element angewendet werden. Sowohl vorhandene Styles, wie auch neue, können beliebig angepasst, erweitert oder entfernt werden. Diese Anpassungen wirken sich sogar auf alle Elemente aus, die diese Klasse besitzen.

Durch all das kann man schnelleres Feedback erhalten und seine Styles testen ohne auf den neuen Build zu warten (auch wenns mit Hot-Reload mittlerweile nicht mehr lange dauert, immer noch praktisch).

Hier noch zwei Features in Bezug auf Styles die hilfreich sein könnten.

Es gibt einen eingebauten Colorpicker, der mit einem Klick auf die Farbfläche geöffnet werden kann. Dieser bietet ein paar praktische Features:

• Verwende die Pipette auf der linken Seite, um ein Element auf der Webseite auszuwählen und dessen Farbwert zu übernehmen
• Nutze den unteren Slider, um die Transparenz der Farbe anzupassen
• Wechsle mit den beiden Pfeilen neben den RGBA-Werten das Farbsystem (Hex, HSL, etc.)

Für die Flexbox gibt es eine Hilfe, die die gängigsten Styles auf einen Blick darstellt. Mit einem Klick auf die Symbole können sie ein- bzw. auch wieder ausgestellt werden. Vor allem hilfreich, wenn nicht oft damit gearbeitet wird und Schwierigkeiten bestehen sich zu merken was wie heisst bzw. was es genau macht.

Console

Die Konsole ist den meisten bekannt dafür, dass sie Fehler ausgibt bzw. über ‹console.log› eigene Einträge fürs Debugging ausgegeben werden. Sie kann aber auch dafür eingesetzt werden, um direkt Javascript-Code auszuführen, entweder als Playground für unabhängige Javascript-Funktionen oder natürlich auch im Kontext der aktuellen Webseite. Dabei können auf Variablen von allen Scopes (global, block & function) zugegriffen werden, wobei die block & function Scopes nur mit setzen von Breakpoints (dazu später mehr) erreicht werden können.

Ein weiteres spannendes Feature sind die Live Expressions. Beliebige Expressions können eingegeben werden, um sie dann live aktualisiert zu sehen, und somit entfällt die Notwendigkeit, dieselbe Expression wiederholt einzugeben.. Sie kann über das Augen-Icon eingeschalten werden und wird dann immer oberhalb der Konsolenausgaben angezeigt.

Zum Abschluss dieses Kapitels noch einen kurzen Exkurs zur Konsolenausgabe:

Alternative Methoden

Die meisten Entwickler kennen und verwenden nur ‹console.log›, aber es gibt auch noch andere Methoden auf dem ‹console› Objekt.

Methode	Bescheibung	Beispiel
.warn	Ausgabe von Warnungen, mit gelbem Hintergrund (und Trace)
.error	Ausgabe von Fehlern, mit roten Hintergrund (und Trace)
.assert	Kombination zwischen if und ‹console.error›
.table	Ausgabe von Arrays, schön formatiert
.time/.timeEnd	Zeitmessung
.group/.groupEnd	Gruppierung von Konsoleneinträgen

Styling von Logs

Bei Konsolenausgabe kann mit etwas CSS gespielt werden, damit etwas besser erkennbar ist,  von anderen Einträgen unterschieden werden kann oder einfach zum etwas Farbe ins Entwicklerleben zu bringen.

Dafür wird ‘%c’ am Anfang und das CSS am Ende der Konsolenausgabe eingefügt. Hier einige Beispiele:

Sources

Der Sources-Tab zeigt an aus welchen Dateien die Webseite zusammengesetzt wird und ist für die Entwicklung mit Javascript der wichtigste Tab fürs Debugging. Hier können nämlich direkt in den Dateien Breakpoints gesetzt werden.

In der Regel ist es aber so, dass man nicht den kompletten Sourcecode in den Browser deployen möchte und die Dateien gebundelt/minified werden. Durch Aktivieren der SourceMaps (https://www.typescriptlang.org/tsconfig#sourceMap) kann das für die lokale Entwicklung umgangen werden, damit die gleiche Struktur wie auch in der Entwicklungsumgebung angezeigt wird (siehe Bild linke Seite).

Jetzt können gezielt Breakpoints gesetzt und der Code untersucht werden, um genau zu erfahren was passiert:

Auf der rechten Seite sind alle Breakpoints aufgelistet die aktuell gesetzt sind und diese können über die Checkbox gezielt ein- bzw. wieder ausgeschaltet werden. Unterhalb werden noch alle Variablen in den verschiedenen Scopes und den Call Stack vor dem Break aufgelistet.

Conditional Breakpoints

Wenn man eine Methode debuggen möchte die sehr oft aufgerufen wird, aber nur an einer spezifischen Condition interessiert ist, kann der Breakpoint entsprechend konfiguriert werden. Mit Rechtsklick auf den Breakpoint und dann «Edit Breakpoint» kann eine Condition spezifiziert werden, wobei Zugriff auf alle Variablen in diesem Scope besteht.

Pretty print

Manchmal ist es schwierig Fehler in der lokalen Umgebung nachzuvollziehen aufgrund komplexer Testdaten oder weil man nicht genau weiss wo der Fehler liegt. Es gibt einen kleinen Trick um sich das Debugging mit einem produktiven Build zu erleichtern. Das Ganze nennt sich «pretty print» und wandelt minified Code auf einer Zeile in lesbaren Code um. Optimierte Namen (Variablen, etc.) werden dabei aber nicht wiederhergestellt.

Network

Alles was übers Netzwerk geladen wird (Sources, Daten vom API, etc.) wird im Network-Tab angezeigt und dokumentiert. Hier können die Requests/Responses ans/zum Backend inspiziert werden, um zu überprüfen was genau gesendet wurde bzw. was empfangen wird. Die Einträge können nach Typen (Fetch, JS/CSS, etc.) oder mit einem Suchtext gefiltert werden.

Eine sehr nützliche Funktion (vor allem bei offlinefähige Applikationen) ist das Throtteling. Mit dieser Einstellung kann eine schlechte oder unterbrochene Internetverbindung sehr einfach und schnell simuliert werden.

Wenn die «Preserve log» Checkbox eingeschaltet wird, führt das dazu, dass die Einträge nach einem Refresh nicht verschwinden und somit auch Logeinträge vor einem Redirect (Login, etc.) angezeigt werden.

Application

Der Application-Tab ist vor allem relevant wenn viel mit Storages (SessionStorage, LocalStorage, IndexedDB, etc.) gearbeitet oder eine Progressive Web App betrieben wird.

Storages

Der Inhalt der Storages wird hier pro Storagetyp in Key/Value-Paaren angezeigt. Es können einzelne Einträge hinzugefügt, bearbeitet oder gelöscht werden, auch das Leeren eines ganzen Storages ist möglich.

Service worker / Background services

Wer eine PWA betreibt kann hier den Status der «Service workers» überwachen. Zudem bietet dieser Abschnitt eine Einstellung, um temporär Netzwerkanfragen direkt abzusetzen, ohne dass sie erst über den ‹Service Worker› geleitet werden.

Außerdem bietet dieser Abschnitt einen Bereich für ‹Background services›, der besonders für Push-Benachrichtigungen in einer PWA interessant ist. Hier können Push-Benachrichtigungen überwacht und getestet werden.

Schlusswort

Natürlich gibt es noch viel mehr Funktionen, die ich hier nicht erwähnt habe wie zum Beispiel Performance & Memory Analyse oder auch spezifische Extensions (Angular, Redux, React, etc.). Wer noch etwas mehr stöbern möchte, um tiefer einzutauchen, hier der Link zur Doku von Google:
https://developer.chrome.com/docs/devtools/

https://developer.chrome.com/tags/devtools-tips/

Und wenn ihr  selbst noch etwas zum Ergänzen habt, dass ihr oft benutzt oder besonders cool findet, gerne in die Kommentare schreiben!