Use standard console logging

Excerpt

Using console logging is often seen as a bad implementation behavior. But it isn't so bad. And there are options for customization.

So here is a primer to use the standard logging features in the browser defined by the standards. When implementing applications based on the standard browser the application can follow the standard by using the given functions and levels of logging defined by the console element.

There are some libraries available for javascript but are made to run server side in nodejs like winston or bunyan. They make a good job there and the size of the code doesn't count much there.

Some also support client side logging like loglevel or debug but they introduce different APIs than the standard console.

Here and in 2 following advent stories I will show how to stick to the standard for in-browser logging and adding features when required.

Standard console features

There is more that just console.log(). This is a short summary of the featured given by the console as a cheatsheet:

Logging
debug(log-data) logging data (verbose)
log(log-data) logging data (info)
info(log-data) logging data (info)
trace(log-data) logging data(info) + stack-trace
error(log-data) logging data(error) + stack-trace
warn(log-data) logging data(warning) + stack-trace
clear() clear the log. Clear counters.
Maybe gets prevented due user settings
Logging data
dir(log-data) logging the DOM element(info)
dirxml(log-data) logging outer HTML/XML(info)
table(log-data) logging array as table(info)
Code Analysis support
count(label) increment and print counter
countReset(label) reset specific counter
time(label) start a timer
timeLog(label, log-data) print timer with optional data
timeEnd(label) print timer and stop
Log formatting
group(label) start a group and indent logs
groupCollapsed(label) start a group unexpanded
groupEnd() reduce indenting
Assertions
assert(true, log-data) does not appear in console assuming everything is ok.
assert(false, log-data) will stop in debugger with stack trace

log-data – a list of values to be logged. First argument can contain placeholders

no return values

The browser supports 4 logical levels of logging severity:

Controlling the shown log in the browser

Most browsers support filtering the generated console output using a filter string and by selecting the shown levels.

The console is always populated completely and these filters apply before showing the logged content.

Example

In the script of this page you can find several logging functions for testing and inspecting the way it works. Here some examples:

Best practices (my ...)

Use a prefix – The first parameter may contain the log reason including a meaningful prefix. This allows easy filtering.

info – Use info(...) for logging on the activity level as a standard.

debug – Use debug(...) for temporary detailled developing aid. As you can see from the api above the debug function is the one that can be used for verbose debugging and can be switched off in the console. When you have to analyze a problem use debug for the detailled level and use info for the oversight.

assert – The assert function can be used to conditionally stop in the debugger and start detailled analysis from this time on.

Clone objects – whenever you have to log a object that changes over time and you need to expand for detailled analysis be sure to clone the object somehow to log the actual values and not show the latest values when expanding. There is a sequence in the examples illustrating this.

Cloning a object (first level) is easy by using console.log({ ...pObj });

See Also

Tags

JavaScript