I’ll be working off of the code from the last two blog posts today and I’ve just added a couple of lines to show you some of the power of the console.
>Quick Dev Tools Sample</
This is a sample paragraph
var paragraph = $('#sampleParagraph');
var paraHTML = paragraph.html();
paragraph.html('New sample paragraph');
paraHTML = paragraph.html();
Nothing special here. I still have the button that upon getting pressed changes the text of our paragraph element. The only difference from the previous blog post’s code is that I have now added a new variable, paraHTML, which I use to just grab the content of the paragraph before and after the change. Additionally you might see that I use console.log(paraHTML) twice. Well, this will play a major part in the blog post soon so remember it as we jump in to Chrome 21, Firefox 14 and IE9 and see how the console works in each browser.
As you can see above, initially the Console area doesn’t look like much. We see a couple of lines related to the ChromeSniffer, which is just a neat little Chrome Extension that allows us to detect what technologies might be behind a website. For example, if you navigate to a page created via WordPress it will actually inform you that this is indeed the case instead of having you attempt to break down a page by looking at the raw code.
Aside from the ChromeSniffer everything is pretty much blank. We can see that at the bottom of the view we have “All”, “Errors”, “Warnings”, and “Logs”, which are simply there to allow us to filter down any potential issues.
You might be thinking “where did this errorVar come from?” and that’s exactly the thing I want to point out. I’ve never defined errorVar and I’m treating it like it exists. Let me just press the button and see what happens.
Aha! An error occurs and is displayed! Not only does the error let me know what kind of error (Uncaught ReferenceError) it also gives me some additional detail, which in this case tells me errorVar is not defined. The error also has an expand/collapse icon next to it (which I expanded for the above screenshot) that allows me to look in to the call stack that existed when this error was reported. You can also see that in the bottom right hand corner we have an indicator which shows off how many errors that have been reported (just one right now, luckily ;))
Let’s just take out that line as it has served its purpose. What if I want to just run through the code I originally wrote for this blog post? What will happen then?
This also works great with objects. Say that I had the following piece of code which creates a new person object and outputs it to the console:
What will this look like in the console?
Well, we first see that we have a line that just says “Object” with the expand/collapse icon next to it. Upon expanding we see that it contains the same fields that we added to our person object! This means that while we’re going through and debugging code we can also just output any of our objects to the console to give us the ability to dive deeper in to them and see if they contain the values we are expecting.
This can also be very useful when debugging using breakpoints. Any time you have a breakpoint in a function you can access all of the variables in scope in the console with intellisense! So all you have to do is switch over to the Console tab and then type away with the variables you have. You can even just type the variable name and hit enter to see the same kind of output we saw with the person object or any of the console.log() method calls we had.
The Firefox/Firebug console looks like the following:
While there is no ChromeSniffer here, initially everything looks pretty much the same. Let’s go through the same steps to see if there are any differences.
Here’s what happened after I placed that errorVal statement in my code again:
Again, we get the ReferenceError with some additional details, and we also get to see which file and line gave this error. One new thing that we didn’t see in Chrome is the actual code that triggered the whole thing. Nice additional detail if you ask me!
Now, taking out the error and pressing the button we see:
Awesome! We get the two console.log() method calls outputted, as well as knowing which lines these came from.
Adding the person object to my page and outputting that:
We get to see our object again! This is all on one line though, which can be a little cumbersome to read and understand. No need to fear though, you can actually click on the object and get the following:
Perfect! While this is now under the DOM tab we can drill down to see each field of our object and their respective values.
Now it’s Internet Explorers turn to show off its chops with the console.
Nothing special so far, let’s check out the error message again.
Well, we’re not sure what type of error it is, but we can still see that errorVar is undefined. Alright, how about we go back to our original code and see the output.
Let’s check out our person object while we can:
Ah, this is a bit of a problem. This is the same message we’d see if we did alert(variableName). We see that it’s an object, but no details about it what so ever. Luckily there is a way to show the details of the object in IE9 – and it does work for other browsers as well! Instead of console.log() we should use console.dir(). Doing that we get:
Much better! There we have the object we’ve been wanting all along! Cue the celebration :)
Was this series helpful to you or did I miss something? Feel free to leave a comment below and let me know! :)
Carl Bergenhem is an Enterprise Solutions Consultant at Telerik specializing in the ASP.NET AJAX and ASP.NET MVC products. He has always been interested in web development and has played around with various web technologies since he was a kid. In his free time Carl enjoys soccer, running and playing his guitar.