This lesson is for PRO members.

Unlock this lesson NOW!
Already subscribed? sign in

Log Levels and Semantic Methods

4:38 JavaScript lesson by

Go beyond console.log by learning about log levels, filtering log output and structuring your output to be meaningful and concise. The JavaScript console object offers many methods to make your life easier - start learning them here!


egghead.io comment guidelines

Avatar
egghead.io

Go beyond console.log by learning about log levels, filtering log output and structuring your output to be meaningful and concise. The JavaScript console object offers many methods to make your life easier - start learning them here!

Avatar
Steve Lee

Really useful thanks. I learnt a few things I'd missed when console grew up.

One you missed out that I often use is console.dir(). This gives you the a pretty print of key props when logging a DOM object.

Also I agree .assert() should be avoided. Put that in your unit tests so it fails your build process!

In reply to egghead.io

Anybody who starts out programming in JavaScript, one of the first things you learn is how to log a string to the console. This works a little bit differently in Node versus in the browser. I'm going to talk to you today about specifically, some browser-related methods that are going to help you to do better logging in your code, when you're working in a web browser.

We all know that you can say console.log some string somewhere in your code and it's going to log out that string. What you may not know is that log is only one of several methods. There's actually a whole bunch of these methods.

Log is intended to be used for general output. It's a general case, if you just need to log something out, if you need to flag some bit of information so that it shows up. It's like the general catch-all. Really, there's a good argument to be made for using some of the more semantic logging methods.

For instance, if instead you were to say console.info some string, you see it shows up, and you've got this little blue icon next to it. If you were to say console.warn some string that shows up as highlighted in yellow, gets a little bit of attention, has that exclamation point there.

If you were to say console.error some string, then not only do you get the bright red icon there, but you've also got the stack trace built in here. Whenever you've got an error, you can easily step through and see where it came from.

What am I missing? There's console.debug. That prints it out in blue. You might be thinking, "OK, great. Why am I going to bother with all of these different things?" Let me show you something. You see this button here?

This is Google Chrome in the console. You click on filter. Right now, by default it's showing all messages. That's fine, but if you only wanted to see errors, like the REPL lines, where I typed, and it got a return value, ignore those.

You can see the log statement is now no longer shown. The info statement, it's no longer shown. The warn statement, it's no longer shown. Only the error shows up. Maybe you want to only see warnings. Maybe you only want to see info. Maybe you only want to see debug, or logs.

This is a good way, if you have a certain class of output, maybe you do want to do console.log for a bunch of stuff. If you're viewing everything all the time, then you'll see all of those, and that's fine. Maybe you want to have regular output that only shows up.

Maybe you put certain things into debug, so that when you're working on your application, when you're running it locally and developing, you'd switch to debug mode and it shows you all this debug output that you're putting out.

It doesn't show you all the other crap that's not actually relevant to what you're doing right now. Obviously, this is something I'm talking about really for when you're in inactive development. You really want to be cleaning up your logs.

You don't want to be dumping a whole bunch of stuff out to the console when you're in production, especially not references to internal objects, or anything that can be used by a malicious programmer to get into your code and change it as it runs.

I hope that you can see from this example that by using these five methods, log, warn, info, error, and debug, you can structure your logging and filter it to get a much more useful set of output as you develop.

HEY, QUICK QUESTION!
Joel's Head
Why are we asking?