Debugging with Chrome DevTools
By now, you know that Chrome DevTools is more than just the elements tab. You’ve probably ventured into the console tab and logged code to test its outcome. But the DevTools goes so much further than that, from checking performance, to testing CSS. There are countless tools that I don’t even know how to use at this point, as a new-bee in the Javascript world.
Today, I wanted to showcase a tool that could be very handy for the new-bee in Javascript, outside of the console and elements tab. This tool, is the breakpoint tool, which can be accessed through the “source” tab of your DevTools.
As a coder, you want to make sure you are constantly testing your code. If you code too much without testing, you may end up with a bug that you were unable to catch because you got too far ahead without making sure your code properly works. When you have bugs (or maybe you just want to check what certain things equate to within your code) Javascript has the handy “debugger”, which you can place at a certain point in your code. Then, when you run your code in the browser, your code will stop once the line of code which has the debugger is hit. If you want to check multiple areas of your code, you can place multiple debuggers. Sometimes as a beginner in coding, we can get debugger-happy and before you know it, we forget to delete some of our debuggers and when we try to run our code we find ourselves hitting random debuggers we placed ages ago. On top of that, writing debugger over and over again is tedious. But at the end of the day, we have to test our code.
Okay, so what about this source tab that I mentioned? In the source tab we can actually set breakpoints, which act just like a debugger, but we don’t have to type anything. we just click the line of code we want our code to stop at when ran, and run our code. Once our code hits the breakpoint, we can use the console to check things as we would with a debugger. We can check the value of certain variables that have been executed thus far in our code, as well as test code in the console. You will also have access to the “step over” and “step into” tools.
Another cool feature provided by the source tab, is the ability to add breakpoints to event listeners. Let’s say you have a button with a click event, and you want to further inspect the element, maybe you don’t remember where the event is located in your code, or you want to test a different outcome. Through the source tab, we have a menu of event listener breakpoints with many different event listener options to choose from. We can go to the mouse drop down and check the “click” option. Now when ever we click anything that has a click event listener attached to it, our code will be stopped on that line of code and we can proceed to test code in the console.
Why is this handy? Like I mentioned in the beginning, using debugger can get messy if you’re not careful. Also, using the breakpoint tools provided, we can easily add many breakpoints and easily view all of the breakpoints on the listed menu provided. As well as easily remove any unnecessary breakpoints by simply unchecking them from our list. All in all it is cleaner and more efficient.
Now, while I’m hoping this article gets you to feel more inclined to utilize the source tab, I also hope this gets your curiosity going and urges you to explore all of the other tabs and tools provided to us through DevTools. As a developer, Chrome DevTools works for us and, if properly utilized, will be our best friend!
