console.log(’8 Javascript Debugging Tips’);


by
21 Mar
March 21, 2013

The webkit developer tools are the single most helpful front-end development resource I have. I use them every day, and wanted to share a few tricks I use to track down bugs or unexpected behaviors in my javascript code. My browser of choice is Chrome,  so all examples and screenshots below will be pulled from the Chrome console.

First, if you’re still using Alerts to give yourself feedback, please stop. The unobtrusive console.log statement will give you feedback that can be much more descriptive, and sticks around for as long as you want it to. To get started, use the shortcut CMD+Option+J (Windows: CTRL+SHIFT+J) to pull up the Chrome console any time. Alternatively, you can right click the page and hit ‘Inspect Element’ to bring the panel up, then select the ‘Console’ tab.

Logging All HTTP Requests Automatically

Screenshot of the javascript console right-click options

Right click in the console to bring up these options

This one is simple, but can save a lot of manual logging, and potentially reveal some unwanted/unexpected/unnecessary network calls. You can right click in your Console to reveal the option to “Log XMLHttpRequests.” This will show you a twirl-down stack of calls that resulted in the sending, and finishing of an XMLHttpRequest (like a jQuery $.ajax() call).

Make your logs stick around

In the same right-click menu in the Inspector Console, you can choose to “Preserve Log Upon Navigation.” By default, the logs and errors in your console clear every time you refresh or navigate to another page. This option will keep them around, which might be useful if you wanted to compare something before and after a change, or if you have code that redirects to another page, and you need to see logs that print before the redirect.

Show a console and the element panel at the same time

Screenshot of

You can open the console tab in addition to another tab. Just click the button that looks like a > and 3 lines of code while another tab is open.

Particularly helpful for when you’re inserting and removing elements from the DOM with javascript. I also use it in conjunction with the ‘Network’ tab to monitor details of ajax requests (if doing this, clear the network tab after the page loads so it’s easier to find your new requests).

Change your document size without changing your window size

Screenshot of the console docked to the right of the window

Dock your inspector to the right to easily test breakpoints without resizing your browser window (which has a few limitations and annoyances)

Screenshot of Chrome extension buttons

Tip: Try hiding some browser extension buttons (right click) — these limit your browser window’s minimum width.

You can dock the inspector to the right of the screen! Click the button in the bottom left with the dark bar on the right (click and hold to reveal the option to un-dock the inspector). Now you can resize your viewport without resizing your browser (grab and drag the divider between the console and the webpage). This is really useful for testing responsive design breakpoints, and as an added bonus, doesn’t limit your min-width (ever wondered why you can’t get your Chrome browser down below a certain width? You’re limited by your browser extensions when resizing the window).

console.log() vs. console.warning() vs. console.error()

Screenshot of examples of logging normal messages, warnings, and errors.

Use console.log(), console.warn(), and console.error() responsibly. Note that console.error() includes a twirl-down stack trace.

Most of the time, using console.log() is all I need, but there are a few other methods that can help from time to time. Use console.warn() to add a bright yellow triangle in front of that log, and use console.error() to include a stack trace with your error message. (Note: there’s also a console.debug(), but I’ve never felt the need to use it over console.log())

Logging objects and arrays you can explore

This trick can be incredibly helpful. Have you ever logged an object and seen this: [object Object]? No more!

Try it out… copy and paste the code above into a console! Note also that at the bottom, you can use the filters to only show a particular type of log (defaults to “All”).

Access local variables

This one is pretty cool. Say something is happening in a function and it isn’t returning what you expected, or isn’t taking the path it should. What do you do? You may start by adding a log statement at the top of the function that prints out all the parameters that are passed to the function, and then another log inside your if/else paths. How about this instead:

If you’re familiar with using breakpoints, this is the same concept, just inline in your code. Like breakpoints, you have access to the scope in your console where the breakpoint/debugger was inserted. Even cooler? Hover over a variable in the Sources tab to reveal its value!

Screenshot of hovering over a variable while paused by a breakpoint or debugger statement

While you’re paused by a breakpoint or debugger statement, you can hover over a variable to reveal its value.

Un-minify (Pretty-print mode)

Screenshot of a minified javascript file in the Sources tab

A minified javascript file in the Sources tab

I learned about this trick at CodeMash this year… I haven’t found a need to use it yet, but it’s still pretty cool. You can un-minify code right in the Sources tab! There’s a little icon with two curly braces that re-construct the minified javascript code (you may lose some variable names if they’ve been shortened to single-letter placeholders during minification).

Screenshot of a minified javascript file, un-minified with the Pretty Print mode turned on

The same minified javascript file, with Pretty Print (de-minification) mode on.

Will Dages

Will is the Manager of Web Development at Findaway World.

More Posts - Twitter - Google Plus

Tags: , , , ,
© Copyright 2017 Findaway. All rights reserved.