Console.log() — Tips

Level up your javascript browser logs with there console.log() tips

The fundamental rule of software development is that software will fail — what separates new developers from experienced ones is how they plan for those failures. Robust and effective logging is an important part of planning for failure, and eventual mitigation. As it is for backend development, logging can be useful for frontend software development, but it goes much further than just troubleshooting and debugging. Effective frontend logging can also make the development experience productive, fast, and fun.

While I’m a big proponent and diligent practitioner of Test-driven development, I love the flexibility, the richness of information, and code confidence browsers provide to frontend developers who make effective use of console.log(). I thought I’d share some frontend logging tips and tricks I’ve learned and incorporated in my workflow over time while building Firecode.io - in the hope that some of these will help you make your development workflow a bit more productive and fun!

I like to divide these tips into two broad categories — quick n’ dirty logging for when you’re actively building and debugging your application, and durable production logging — to know when your app’s working as expected and when it’s not.

Don’t use console.log().

Yes, that’s right. I don’t use console.log(). Well, ok I write wrappers that use console.log() (more on that in the production logging section), but if you want to log something in your app to see what’s going on, use console.trace() instead. In addition to giving you everything console.log() does, it also outputs the entire stack trace so you know where exactly the message is emitted from

Use ES6’s computed property names to identify your objects and avoid variable name confusion

This one is straightforward — use ES6’s computed property syntax and wrap the objects you wish to log in curly braces inside console.log() - i.e. use console.log({user}) vs console.log(user). You’ll find them neatly logged with the variable name set as the key, and the value as the object itself. This is especially useful when you’re in a hurry and want to log multiple objects in the same console.log() command.

Embrace tiered log levels — error, warn, info

console.log(param) by default logs at the INFO level - however, you also have 3 other logging levels at your disposal which you should make use of - console.debug(), console.warn() and console.error(). Besides formatting differences (notice the different colors?), the browser’s developer console also lets you easily filter out logs at different levels with a convenient dropdown to declutter your logs.

When logging lists of items, use console.table()

This one is self-explanatory and one of my favorite console functions — if you ever need to log a list of objects, give console.table() a try.

Granular performance profiling with console.profile() and console.time()

Want to profile an exact user flow in your application to find hot spots? Trigger console.profile(profileName) at the start of the action, and console.profileEnd(profileName) at the end to inspect the CPU profile for the flow.

Count labelled executions with console.count()

This one’s one of those console functions I haven’t found much use for personally, but it’s there if you need it. console.count(label) can help you know exactly how many times a piece of code gets executed - which could be useful for finding and eliminating race conditions and other scenarios.

Summary

I really hope these tips make your frontend development experience a little more productive and fun! I’ve obviously only touched the surface of logging ninjitsu in this post, Thanks!