Debugging in JavaScript may seem like a daunting task. With all the build processes and code manipulation, it can be hard to track down certain bugs. This post will talk about some tried and true debugging tips and techniques that can help track down bugs more quickly. Many of the approaches will be centered around Chrome, although Firefox and Safari have very similar techniques and tools.
Enabling Source Maps in WebPack to Locate Bug Files
First things first; if there is a build process going on that packs JavaScript assets, such as WebPack, enabling source maps is a necessity. WebPack (a technology we use in multiple CQL projects) makes it pretty simple to generate source maps – you just add a devtools: 'eval-source-map' property. Now, stack traces will show you the source file with the bug. Another bundler that has generated a buzz around the office is Parcel, a zero-configuration bundler that has source mapping enabled by default.
Preventing JavaScript Execution with Debugger Keyword
There are ways of stopping JS execution so we can gain insight into exactly what’s happening at execution time. The first method is the JS debugger keyword. This is a great way to stop execution if we happen to know where the bug is occurring already. Just open the source file, inspect the code (maybe it’s an easy bug when we look at it with that skeptical eye), and type debugger; some lines before the bug.
Next, open the inspector in Chrome (Command+Option+I on Mac, Control+Shift+I or F12 on Windows), reload the page, and rerun the problem code again. When JS execution gets that new debugger line, the focus will shift to the Sources tab. The main window shows the file, and the right sidebar is where the code navigation/variables/call stack/fun stuff can be found.
Note that a Console can also be opened while the Sources tab focused, just press Esc! The console can be used to test code against local or global variables. For example, if there’s a variable called`title holding a string, by typing title., Chrome will start suggesting methods that can be used on a string like length. Thanks to Chrome’s Eager Evaluation, the code doesn’t need to be run for many methods, it will simply show the output before running. You can try this now in a console – type any string (like “debugging is fun!”) and start using some string methods on it.
Back to the code navigation in the right sidebar. The main navigation buttons are the Resume script execution, Step over next function call, Step into next function call, Step out of current function, and Step. Resume script execution does just that. If we are done debugging this particular area of code, press this and the code will continue until it is complete, or it hits another breakpoint. Step is the most basic navigation option. This simply moves to the next line in the code. If the line happens to call another function, this will step into that function. Step over the next function call skips whatever the next function is. If we are stopped on a line that calls another function, but we don’t want to step into that other function, this button will ignore that function.
What to Do When Debugger Keyword Doesn’t Hit
Sometimes, the bug may be a little harder to find than first expected. Perhaps the debugger added to the source file didn’t hit. This can indicate that there is a bug occurring before the spot originally suspected. In this scenario, there’s another handy button in the Chrome Inspector’s Sources tab, the “Pause on exceptions” button.
When the code hits an exception, the execution will stop at the exact line the execution was thrown. The Call Stack area is the answer this time. It shows all of the events that led up to the current exception, with the most recent call at the top. Just look for the call that comes from your source file. This is where the bug probably lives. The code written in the source file may be sending the wrong type to some method, or maybe missing some property on some argument somewhere. The point is, now we have another place to investigate this bug, so a debugger keyword can be used, or a breakpoint can be added right in the sources tab. To add a breakpoint right in the sources tab, open the problem file by using Command+P or Command+O (Contrl+P/Control+O on Windows) and typing in the file name, then clicking on a line number. Execution will stop the next time it hits this line.
Deactivating Breaking Points to Resume Execution
By the time a bug is fixed, there may be debugger statements and breakpoints lying around everywhere that we may not need to stop at anymore. In this case, use the “Deactivate breakpoints” button. When execution is resumed again, it will no longer stop at breakpoints.
Other Debugging Techniques Helpful for Chrome, FireFox, and Safari
Although all of these techniques focus on Chrome, it should be noted that all of them can be used in Firefox and Safari as well. Firefox and Safari both call their Sources tab “Debugger,” and both can be open with the same keyboard shortcuts. There are other popular JS libraries and frameworks that have their own Chrome Extension. A few that I found helpful are React and Redux Devtools, as well as Vue.js Devtools, and even jQuery specific extensions. These tools may be implemented in different ways throughout Inspector, but all provide library-specific ways of looking at your code at runtime.
CQL has extensive experience in various scripting languages including JavaScript, Ruby, VBScript, and more. If you are looking for support or help in debugging your brand or ecommerce site, contact us today.
