This blog post is for programming developers who often use a Chrome Web browser tool called Chrome Developer Tools. The first part will describe three basic tabs, namely Elements, Console and Source.
Knowledge of the basics of Developer Tools.
Chrome Developer Tools is a tool that developers, especially frontend developers, that is. the interface of the web application itself, they use daily. I suspect that the vast majority of readers already know the basic functionality of this tool. You know for sure what a Console tab is, you know that you change HTML and CSS when you test something, that you follow the Network tab and the like.
But have you done anything beyond that? In this post, we will also mention some of the features offered by this tool, and you have not had the opportunity to take advantage of them so far.
The Elements tab is the part you use most often when changing HTML and CSS, often for testing purposes (what this block would look like if it changed color).
You can also do the following in this tab:
- Creating your own color palette that you can later use for any web application you develop (select an element, click on a color and then click on the second up/down arrow icon, after which Color Palettes will open and in your Custom section add your pattern for colors)
- Various options when you select an HTML element and right-click, then you get the ability to call operations such as Hide element (same as if you added CSS style visibility: hidden), Force state (to apply some state to an element eg hover or visited, useful when you want to see what that element looks like when it goes into another state), Break on or DOM breakpoint (useful when doing a debug of an element from the DOM, e.g. subtree modifications), Scroll into view, and a number of other actions
- Computed styles, showing only those CSS styles that apply over the element as well as the Box Model
- Event Listeners, where you can check which events are pinned to an element
The trick: Check what happens while holding down Shift and click (left click) on the color, when in the Styles section, ie. in mode when changing CSS through a browser
One of the most commonly used tabs. Most often you use it when tracking bugs, doing the debug process.
One of the interesting things you may not have used so far is the Preserve log option. If you click this option, when you go to the second page of your web application the log previously printed in the console will not be deleted, so you will be able to follow all the actions that have been done on the previous pages as well. I know it can be useful, I was glad when I found this option 🙂
Did you know that you can use the $jQuery selector in the console? Try to see for yourself.
You have used it in situations where you are debugging JS through the browser, or just watching if your old JS file is still being downloaded, the cache has not been deleted, so be happy if that’s the problem.
Did you know that the CSS you change while in Styles (Elements tab) can be saved directly locally? Yes, this is possible by choosing Filesystem instead of Page. After that, you just click Add folder to a workspace, add a folder of your project that is now directly part of the browser. Try changing CSS now and see what happens when you refresh the page. And your local code, check what’s going on with it.
Debugging through the browser is possible. For a Chrome browser, this is done by opening the sources tab and selecting the file where you want to add the breakpoint. Also, if you add a debugger line of code in the code, the code execution will stop on that line. Now look at what some parts of debug mode mean:
- Watch for monitoring the value of variables, changes as the code executes, gradually
- Callstack, you can see the functions that are put on the stack, the function that is currently running is an easy-to-see arrow
- Scope, in what scope is the piece of code currently being executed
- Breakpoints, you can deactivate them, add new ones, and more
- Stepping, stepping through a debug procedure, you have multiple modes (resume script execution, step into next function call, step out of current function, and step)
- Blackboxing, when we don’t want to do debugging within 3rd party packages
Can individually or through settings, patterns
- Conditional breakpoint, only in certain situations to activate the debugger (right-click on the line you are debugging and select Add conditional breakpoint…)
- XHR / Fetch debugging response from the server, processing requests containing specific parts of the link
The second and final part of the Chrome Developer Tools blog post will cover Network, Performance, Audits and Memory tabs.
Until then, hello. I wish you all as few bugs as possible 🙂