Pretty Printing
Myself and Addy spent a few hours banging our heads against a wall trying to understand why our samples using our new Service Worker libraries (sw-helpers)were failing. It turned out to be a stupid quirk of the libraries, bugs were raised etc, but ultimately logs would have helped.
One of the reasons these libraries aren’t logging anything to the console is that in previous service worker libraries, it becomes “spammy” pretty quick.
While I’m not 100% sure our new libraries can avoid drowning the console (although we’ll try), one thing that I often wanted from our old libraries, was access to more information about the current state from a log, while also reduce the size / number of logs.
For example, in the image above the log: ‘[sw-toolbox] Strategy: fastest [https://………..]’ has a few issues:
- The message doesn’t actually explain anything. “Strategy: fastest” doesn’t mean anything.
- There is information lost (i.e. what was the original request, what cache will it look at, did the strategy find a cache hit or did it go to the network, what rule intercepted the original request).
That being said, sw-toolbox has these super short succinct messages, to reduce the amount of noise in the console.
To try and enable sharing more information from out library without growing the size of our logging, I started digging into the console options for grouping and coloring logs and it’s a kind of great / upsetting state of affairs.
Console Groups
Grouping of logs is awesome, you simply open and close a group and any logs between those will be added to that group.
There are a few options to call out with this.
You can call console.groupCollapsed() so that the group is initially closed.
You can also set a title on these methods.
Grouping helps if you have a chunk of information you’d like to expose to developers but it’s only relevant some of the time.
Console Group: Support
The support of console.group() is kind of wonky.
Chrome and Safari are good for both group() and groupCollapsed()
Firefox supports both methods, but it doesn’t actually collapse groups, meaning callingconsole.groupCollapsed() doesn’t save space in the console.
Also worth calling out that Firefox shows no title by default — which I quite like.
Edge “has support” for these, but it’s broken. The logs seem to come out of order.
These differences are frustrating. Firefox can result in verbose logs and Edge is just unreliable (i.e. it feels pretty damaging to use console grouping in Edge at the moment).
Console Color
I wanted to explore the use of colors in the console, largely because it’s super helpful in terminal logging. Turns out that using the %c format specifier in a log message, followed by CSS styles enables just this.
What’s great about this is that you can apply multiple format specifiers (i.e. include multiple ‘%c’ in a console message).
Console Color: Support
Ah the good old question of support.
Chrome, Firefox and Safari support colors.
There is one gotcha with Firefox. Colors aren’t supported in the title of groups:
Colors are unfortunately not available in Edge *sad face*. (No issue for this on the issue tracker).
It’s a struggle to deal with these issues in that where it’s not support, the log will actually print ‘%c’ (Compare the logs in the image above).
Pretty Printing
With all of this, I’ve been toying with the following in our new service worker libraries (sw-helpers).
At the most basic level, these libraries will have a nice spanner emoji (cos reasons), a colored log level (to indicate importance of the message) and I’ve colored the primary message to make it visually separate from the pages logs.
Additional pieces of information are displayed under “Extra Information”. This restricts the amount of data displayed by default to just the log message while allowing extra information to be added.
Lastly, if there is a relevant error, its promoted to the top group since it’s likely to be relevant to the developer and it’s default coloring helps.
In Firefox I’ve had to use console.log() to print the top level message instead of making it the title in console.group() (This doesn’t break the visual result while supporting colors). The one downside to Firefox is that the logs could be verbose since groups can’t/don’t collapse.
In Edge, I’ve just fallen back to logging, no groups and a no colors.
I’m fairly certain I’m going to change the output on Edge — the log has no structure and the filename and line number added by DevTools exacerbates the cluttered look of the logs. (Maybe just logging extra information as an object will trigger a DevTools group like it’s done with the Array)
There is an additional goal to allow developers to filter based on log level: info | debug | warn | error or supply a custom function to only log specific messages, which should reduce the number of logs / enable better debugging for developers.
It’s been interesting viewing logging in the light of “how can we give developers friendly and informative logs” and interesting exploring support for these features.
I’d love to hear what people think of this kind of logging — does it look useful? Should a message be enough (i.e. don’t use groups for extra info)? Does it look too verbose in Firefox and actually less information is better in that case?
If you are reading this and wanting to add styling to your logs, it’s worth checking out Log and console.style, two libraries that aim to make it easier to write styled logs by using markdown or inline HTML.
As always H/T Addy Osmani for review.
Update March 25th 2017
Firefox has support for collapsible groups in version 55. (Thank you @nicolaschevobbe for letting me know — issue for tracking updates is here.)
