debugging > Chrome DevTools
In this tutorial we are going share everything you need to know about debugging web applications in your Google Chrome web browser. The good news is that you only need to know one tool: the Chrome DevTools. Already installed in your Google Chrome web browser, the Chrome DevTools is technically just one panel in your browser. But this is an absolutely massive and incredibly useful tool!
What are the Chrome DevTools?
How to open the Chrome DevTools
To open the Chrome DevTools, right-click on any website and clicking “inspect”, the DevTools will open and highlight the selected DOM element in the Elements panel.
You can also use the keyboard shortcut
CMD + Option + J on Mac or
CTRL + SHIFT + J on windows to open the Console panel.
The Elements Panel
The Elements panel lets you view and edit a page’s DOM. This is different than viewing the page’s underlying HTML returned from the server.
HTML VS DOM
As explained by Google Developers:
If you want to view a website’s HTML sent from the server, simply right click on the page and choose “View page source”.
You can access the Elements panel by either right-clicking any element on the page and choosing “inspect”, or just click on the Elements panel once inside the Chrome DevTools.
Now that we have our DOM at our fingertips, let’s explore some options.
Inspecting a DOM node
If you right-clicked on an element and clicked “inspect”, you should now be viewing that element highlighted in the DOM tree. To select another element on the page, click on the Inspect icon and hover over an element on the page and click once on the highlighted area that matches the element you want to inspect.
Why are we inspecting DOM nodes again?
Here are some reasons we inspect DOM nodes:
- View the current HTML or CSS properties of a particular element
- Change the HTML or CSS to see what effects our changes have on the page
- See how a particular element’s styles are generated from CSS
- View the URL of a particular HTML image
Editing the DOM
Editing the DOM will be reflected live on the page you are viewing, so it’s the perfect tool to check how your new updates to HTML or React components would look.
Double-click on a DOM node to edit the properties or the text inside that node. You can start typing right inside the node. This text or properties are reflected on the page. Useful if you want to see what new text copy would look like on the page.
Editing the HTML
If you right-click on an element and select “Edit as HTML”, you are then given a text field to fully edit the HTML content comprising that element. This is useful if you want to add or remove certain HTML elements around that element to observe new behavior. A common use case would be if you are building a flexbox row component and aren’t sure what effects a new component would have on the row. You can easily add new elements inside or around any element on the page with “Edit as HTML”. You can then edit the CSS of this new component to add new properties. We’ll discuss this shortly. Of course, you know that these changes aren’t saved in your application source code, so they are perfect ways to quickly check a new HTML structure without adding and deleting these elements in your code. Simply refresh the page and you can edit the same component again and again.
Editing the CSS
Now that we discussed editing the HTML, let’s talk about the Styles panel on the side of the Elements panel. This panel is quite possibly the most important part of the Elements panel. Not only good for debugging CSS, the Styles panel helps you develop an understanding of how CSS works. Do not underestimate this panel and use it all the time when writing CSS.
Viewing and Editing CSS for an element
With the Elements panel open, inspect a DOM node that you want to check styles for. Over on the right you will see the Styles panel. This might look overwhelming but it is structured in a very specific way that will help you quickly understand what’s going on with element’s styles.
The Styles Panel
The Styles panel itself is organized by CSS rules that match that element. From top to bottom, each rule section is positioned in order of CSS specificity. Check out this article for an explanation of CSS specificity.
For example, let’s say in your CSS file, you have targeted CSS rules for a child element, a parent element, and the body. To keep it simple, let’s say each of those rules set a different color for a paragraph element. The child CSS rule would override the parent and body styles because it carries a higher specificity weight, so that color would be used for the child. So even though there are 3 different rules applying to the paragraph, the child rule wins and the element is set to the color of that rule. But that information about the parent styling isn’t lost. In the Styles panel, you can scroll down to see the other style rules for the parent, and then the body! These are crossed out because they are overridden by a more specific CSS style. Isn’t that cool? Imagine if we were trying to set a style on the body and didn’t know why it wasn’t being used. The Styles panel not only tells what rule is being applied, but it shows us all the possible rules that could be applied!
Even going all the way down, we can see the user agent stylesheet rule, which is the browser’s default set of CSS rules for all html elements.
CMD + P on Mac or
CTRL + P on windows. You then should see a dropdown to find the file in your app. If you are writing React code, you may see multiple files of the same name, one will contain the source-map for your React file.
To set a breakpoint, click on the side of the file near the line number, as shown in the gif below. Then, execute the code that will trigger the breakpoint. The line of code is now highlighted, which signals that the code has paused execution on that line. So you can observe certain data in the code at this point by hovering over the variables you want to inspect. This is essential to debugging- quickly viewing the current state of your app at any point will give you great insight into how your app works, useful especially when you have a bug and need to know what's happening.
Examining the call stack
Once a breakpoint is triggered, you can now step through the call stack. As you can see in the gif below, function A calls function B, which calls C and then D. as we click on the functions in the call stack, our breakpoint moves "up" to where the current function was invoked. We step through the call stack to trace a particular function to down to where it was called. This is useful if you want to investigate a chain of events in your code. "What called this function, what were the arguments it used? What called the function above that?"
For an in-depth guide to setting breakpoints, check out the Google Developers Guide .
Debugging React Code
To learn more about debugging React apps and see these concepts in action, check out our course React Beginner Challenges.