Useful Javascript debugging tips you might not know

Rickard DahlstromJavascript, Tech Stuff, Web Development18 Comments

The Raygun team is made up of a bunch of nerdy folk just like yourself. Occasionally they write about tools they like and thoughts they have about dev-type topics. This week we’ve got Rick, our longboarding-freediving-Swedish speaking front-end dev talking about ‘things you didn’t know about Javascript debugging’.

Knowing your tools can make a major difference when it comes to getting things done. This is a list of small debugging tips you probably didn’t know but soon won’t live without. In this post, most of the tips are for Chrome inspector even though my favourite tips are for Firefox. Many of these tips will work in other inspectors as well.

Quick find your DOM elements.

Mark a dom element in the elements panel and use it in your console. Chrome inspector keeps the last 5 elements in its history, so the last marked element will be displayed with $0, second to last marked element $1 and so on.

If you mark following items in order’item-4′, ‘item-3’, ‘item-2’, ‘item-1’, ‘item-0’ then you can access the DOM nodes like this in the console.

Debug javascript

Display object as tables

Sometimes it can be a bit messy to view a lot of data with console.log. You can display a list of objects as a table to view complex sets of data more easily.

Will output…

console.table

console.table

Get the stack trace for a function

If you’re using a javascript framework you know that it quickly produces a lot of code. Views are created, events are triggering functions and in the end you want to know what caused this function call. Since Javascript is not a very structured language it can sometimes be hard to get an overview of what happened and when. Especially when you jump into someone else’s code. This is when console.trace (or just trace in the console) comes handy.

Imagine you want to see the entire stack trace for the function call funcZ in the car instance on line 33:

Line 33 will output…

Console trace

Console trace

Now we can clearly see that function func1 called func2 which called func4. Func4 created an instance of Car and then called the function car.funcX and so on.

Even though you think you know your script well this can still be quite handy. Let’s say you want to improve your code. Get the trace and your great list of all related functions. Every single one is clickable and you can now go back and fourth between these functions. It’s like a menu of functions just for you.

Quick find a function to debug

Let’s say you want to set a breakpoint in a function. The two most common ways to do that is probably to find the line in your inspector and add a breakpoint. Another way would be to add a debugger in your script. In both of these solutions, you have to click around in your files to find the particular line you want to debug.

What is probably less common is to use the console. Use debug(funcName) in the console and the script will stop when it reaches the function you passed in. It’s quick but the downside is it doesn’t work on private or anonymous functions. But if that’s not the case it’s probably the fastest way to find a function to debug. Note that there’s a function called console.debug which is not the same thing.

Type debug(car.funcY) in the console and the script will stop in debug mode when it gets a function call to car.funcY.

debug(car.funcY)

debug(car.funcY)

Black box scripts that are NOT relevant

Today we often have a few libraries and frameworks on our web apps. Most of them are well tested and relatively bug free. But we still debug our own scripts and the debugger still steps in to all those files that have no relevance for this debugging task. The solution is to black box the script you don’t need to debug. This could also include your own scripts. Read more about black boxing in my previous article javascript-debugging-with-black-box.

Find the important things in complex debugging

In more complex debugging we sometimes want to output many lines. One thing you can do to keep a better structure of your outputs is to use more console functions like: Console.log, console.debug, console.warn, console.info, console.error and so on. You can then filter them in your inspector. But sometimes this is not really what you want. It’s now that YOU can get creative and style your messages. Use CSS and make your own structured console messages.

will output…

Custom console message

Custom console message

In the console.log() you can for example set %s for a string, %i for integers and %c for custom style. You can probably find better ways to use this. If you use a single page framework you maybe want to have one style for view message and another for models, collections, controllers and so on. Maybe also name the shorter like wlog, clog and mlog. It’s time to use your own imagination.

Watch specific function calls and it’s arguments

In the chrome console you can keep an eye on specific functions. Every time the function is called it will be logged with the values that was passed in.

Monitor

Monitor

This is a great way to see what arguments are passed into a function. But I must say it would be good if the console could tell how many arguments were expected. In the above example func1 expect 3 arguments but only 2 is passed in. If that’s not handled in the code it could lead to a possible bug.

Quickly access elements in the console

A faster way to do a querySelector in the console is with the dollar sign. $(‘css-selector’) will return the first match of CSS selector. $$(‘css-selector’) will return all of them. If you are using an element more than once it is worth it to save it as a variable.

debug javascript

Post man is great but Firefox is faster

Many developers are using Postman to play around with ajax requests. Postman is great but I must say it’s a bit annoying to open up a new browser window, write new request objects and then test them. Sometimes it’s easier to use your browser.  When you do so you no longer need to worry about authentication cookies if you are sending to a password secure page. This is how you would edit and resend requests in firefox.

Open up the inspector and go to the network tab. Right click on the desired request and choose Edit and Resend. Now you can change anything you want. Change the header and edit your parameters and the simply hit resend.

Below I present a request twice with different properties.

Edit ajax request

Edit ajax request

Having said that postman is still great and has other benefits.

Summary

This article may not change the world but I hope those small tips and tricks will make your coding day easier and more fun. If you like to speed up your workflow I can also recommend you to read:

Want to make Javascript debugging even easier with your own apps? Raygun has a free trial available and works with Javascript. Get started today and start blasting away software errors in record time!

Or, if you’d like all your JavaScript questions answered, book a demo of Raygun with an experienced team member here. 

We would absolutely recommend Raygun to any business which relies on healthy software to serve there customers. Andrew Schofield, Chief technology officer at Timely. Take a free 14 day trial. Request a short demo of Raygun.

18 Comments on “Useful Javascript debugging tips you might not know”

  1. Pingback: Web Development Research June 11, 2015 - Angelique Roussos

  2. Pingback: Javascript debugging tips | DiscVentionsTech

  3. Steven Langbroek

    I’d like to share what’s useful for me, as a front-end engineer working on mobile products framed in a webview:

    – Have your iOS/Android developers enable Remote Debugging in your webview for the testversions of your app. Browse to chrome://inspect in Chrome for Andoird, or open the Develop toolbar in Safari for iOS.
    – Have your app throw in development mode, but catch and log it on production. This is useless without Source-maps in a production app, but if you have sourcemapping you have a pure, unadultured debugging experience in your production app. Be wary though: inline source-maps is extra kb’s in your app’s payload.

    For me, being the primary developer on a mobile app that lives in a WebView the first tip is most crucial. Be prepared to write a proxy server to reproduce your production environment, and be able to add breakpoint, debugger statements, console.log’s.

  4. Pingback: Javascript debugging tip | DiscVentionsTech

  5. Pingback: Use Linters For Safer Coding With Less Javascript Errors

  6. Pingback: Using Linters For Faster, Safer Coding With Less Javascript Errors | Raygun

  7. Charles

    You can also replay ajax requests in chrome. Just right click on a request and hit “Replay XHR”. No need to switch to post mans or Firefox. Great article!

  8. Pingback: LISTA ESENCIAL PARA DESARROLLADORES WEB #2

  9. Pingback: Daily links 2015-10-09 | Marcin Kossowski

  10. Pingback: Weekly links 2015-10-11 | Marcin Kossowski

  11. Pingback: My readings in 2015 week 41 | My path to become awesome dev

  12. Pingback: Daily links 2015-10-14 | Marcin Kossowski

  13. Pingback: Wednesday is Link Day Still Breathing - online home of Chris Taylor - web developer, musician, geek

  14. Pingback: Daily links 2015-11-19 | Marcin Kossowski

  15. Pingback: The (dark) Art Of Debugging [link] | I really need to think of a clever name for my blog

Leave a Reply

Your email address will not be published. Required fields are marked *