Everything You Kneed to Know About the Developer Console

Published in WordPress.

Good professional knows their tools. One of the main tools that WordPress developers have at our disposal is the JavaScript developer console included in our browsers. In this post, we will see everything you need to know about the browser developer console, along with some tricks and curiosities that, perhaps, you didn’t know about.

How to Access the Developer Console

First things first: let’s see how you can open your browser’s developer console. If you’re a Firefox user, just click on the menu (upper right corner) and look for the Web Developer option, as you can see below:

Developer options in Firefox
You will find the Firefox developer options in its menu, in the upper right of the browser.

Then, select Web Console:

JavaScript console in Firefox
Once inside the developer options menu, look for Web Console to open the JavaScript console.

and the console will show up in your browser, as you can see in the following screenshot. Remember that it is possible to configure where you want the panel to appear exactly. You can even set it to appear in a separate window (which comes pretty handy if you’re using multiple monitors).

JavaScript console in Firefox
JavaScript console in Firefox.

If, on the other hand, you are a Chrome user, the procedure is very similar. Simply access its menu, select More Tools and then Developer Tools:

Chrome Developer Console
To open developer tools in Chrome, open its menu, search for “More tools” and select “Developer tools.”

How to Use the Developer Console

Our browser’s JavaScript console is extremely helpful to debug our code, see what our scripts are logging, and run small commands and see their effects on the web in real-time. As a plugin developer for WordPress, the main utility the console has for me is obviously debug, so let’s see in detail what it offers precisely.

#1 Different Log Levels

The first reason why a developer usually opens the JavaScript console is to debug their code. When an error occurs or something is failing, you’ll probably find some info about it in the console. You can even launch your own informational messages, warnings or errors when you want!

Logging levels
Different log levels in the console, depending on the importance (or severity) of the message you want to display.

In the previous screenshot, for example, we see that the console object (global object whose goal is to help us debug code) has different methods for writing messages in the console:

  • debug and log show plain messages.
  • info shows information messages. In Firefox they show an “info” icon next to the message.
  • warn shows warnings, usually pointing out a problem or something that is not quite right. It is usually highlighted in yellow and with a warning icon.
  • error is usually reserved for the most severe errors (that is, things that have really failed). It is shown in red and also prints a stack trace (that is, what function generated the error and all its callers).

The advantage of using different log levels is that we can choose at any time what messages we want to be displayed. For example, in the following screenshot we have deactivated the Info and Debug messages:

Show or hide different log levels
The advantage of using different levels for the different types of messages that you display per console is that you can filter the messages according to their level, so that you only see the ones that interest you.

#2 Monitoring Execution Times

In agile, you’ll often hear this: “make it work, make it well, make it fast.” After writing some code “to make it work,” it’s not unlikely that the result is slow and inefficient. When this happens, it’s important to identify where are the bottlenecks and address them.

Although there are tools such as profilers to find the culprits and understand exactly what’s going on under the hood in great detail, sometimes we want a “quick and dirty” solution. That is, we simply want to identify the slowest function in our code… and simple timers are great at this task!

If you want to know how long a particular piece of code takes to run, start a timer at the beginning of the code (console.time) and stop it (console.timeEnd) when your code finishes:

console.time( 'Timer' );
// code we want to monitor...
console.timeEnd( 'Timer' );

When the code reaches the timeEnd, you’ll see the time it took to run:

Timer: 655ms - timer ended

Notice that when we start and stop a timer, we give it a name (in my example, “Timer”). This is because we can create as many counters as we want, each with its own name, and have them all at once running.

# 3 Automatic Counters

If you are interested in controlling the number of executions of any function in your code or log the number of times a loop runs, use console.count. Each time the function is executed, you’ll get a new log in your console with the current value of the counter:

Counters using the console.counter method
Counters using the console.counter method.

#4 How to Format Your Logs

Logs are here to help us understand what is happening with our code. But that is only possible if we write logs that we can later understand…

Text Strings

At the beginning of this post, I briefly talked about all the log methods console has. The examples I shared printed some plain text. That is, this statement:

console.log( 'Hello world!' );

printed this text:

Hello world!

What if we wanted to print an object instead? Well, this:

obj = { x: 1, y: { a: 'hola' } };
console.log( obj );

becomes this:

Show an object in the console
How to display an object in the console.

But what if we want to log multiple things? Do we have to use multiple calls to console.log? Well, the answer is no, it’s not necessary. We can log everything we want with a single call:

How to write multiple variables in a single log message
How to write multiple variables (even of different types) in a single log message.

Grouping Logs…

When we start having a lot of logs in our code (like, for example, here):

the result can end up being a bit confusing because all logs are merged into a single stream of text:

Retrieving x...
Retrieving y...
Compute result using 2 and 3
Getting max value
Result is 6

Luckily, the console object offers a couple of methods to solve this problem: group and groupEnd. With them, we can group our log messages. Just create the groups (for instance, one group per function):

and they’ll show up like this:

Nesting log messages
You can group log messages and thus facilitate reading.

Tables

When we work with data collections, it is not always easy to visualize them. For example, imagine we have a list of items like the following:

data = [
  { id: 1, name: 'David', surname: 'Aguilera' },
  { id: 2, name: 'Ruth', surname: 'Raventós' },
  { id: 3, name: 'Antonio', surname: 'Villegas' },
];

If we console.log them, this is what we get:

Flat log of an object
If you write any object with console.log, it will be displayed in a more or less friendly way.

which is more or less OK, until we have more objects with more fields each. When facing this type of data structure, I recommend you use console.table for logging it:

Formatting data as a table
When you have a collection of data (usually, objects in an array), it is best to format them as a table.

#5 How to Correctly Display Complex Types (Objects and Arrays)

Finally, I would like to end today’s post with something that not many developers know about… Let’s say, for example, that you are working on a project and want to see what the value of an object is before and after updating it. To do this, it is likely that you will console.log the variable before making the change and afterward, as you see in the following GIF:

Log of an object
If you log an object, the result can be misleading… Updating the object changes a previous log!

In the previous example, we log an object that contains a value set to 1. We then update the value to 200 and log the object again. One would expect the first log to always show the original value (1), but notice how, when we expand the object, it actually shows the new value 200. What is happening?

Basically, a log message has a reference to the object and, therefore, when we expand it, it shows us the object as it is now and not as it was when the log was made. Damn mutability!

To solve this problem, just send a copy to the log (libraries such as lodash and its cloneDeep method make this very easy). This way, the first object logged will be a copy that can’t be mutated (because you won’t have a reference to it):

Log of a cloned object
If you want to make sure that what you see in the log is the value that the object had at the time of making the log, clone it before.

And that’s all for today! I hope you liked this post. If you want more information about everything you can do with console, check out the documentation in MDN. Don’t forget to share it with your friends 😉 And if you do something different or have any advice to share with our readers, leave us a comment 😇

Imagen destacada the Tim van der Kuip on Unsplash.

Leave a Reply

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

I have read and agree to the Nelio Software Privacy Policy

Your personal data will be located on SiteGround and will be treated by Nelio Software with the sole purpose of publishing this comment here. The legitimation is carried out through your express consent. Contact us to access, rectify, limit, or delete your data.