Cross-Console for Better Logging in JavaScript

During web app development, there is little reason to need to handle a cross-browser console interface. In fact, most users today will have no issue if something does get sent to a console while they are browsing (where in the past it could be a JavaScript error event). Unfortunately, when working on a team or in an unfamiliar browser, sometimes sending something to the console while debugging is useful but never gets cleaned up (but in reality you should be debugging with [breakpoints](http://stackoverflow.com/search?q=how+to+set+breakpoint+javascript)). Proper code-review prior to a using code in a production scenario should catch the mistake, but it’s smart to always have that automated backup to protect the code. A quick, robust script will give you full control and blockage of any wild console as well as give you some flexibility to control the console easier using environments and modes.

TL;DR; View it on Github Pages or View it on GitHub

Console Log being Controlled

My coding efforts involve using breakpoints and source control assets in a developer tool (Firebug, Webkit Developer Tools, IE Developer Toolbar.aspx)). The console still serves a purpose if not using it for debugging; it’s a great place to put your code logs and catch the nasty bugs that get confused in the JS Vm’s debugging efforts. When something happens in the JavaScript that should not have happened, (like a 500 from an API, or an If/Else state that is unrecoverable) dropping a console.error to report on that is a good practice. But it’s necessarily wanted/needed in production code, but it is helpful to have that notification while actively developing. This means you could either remove all of that code prior to production, or find a way to not run in while in production. My code solves this dilemma and a few others by actively taking over window.console when you want it to, and not when you don’t want it to. Akin to Paul Irish’s quick log abstraction, except taken to a much deeper level with more features.

I will refer you to my README for the rest of the information

Cross-Console script

Sometimes you just need to control the console. This script provides you with a way to control and take advantage of your console for what it was meant to do (log stuff). Leave the debugging to your breakpoints, start logging your code!

Features

  • attempts to implement console in all environments, or extends the console available.
  • can have console behave differently in development versus production
  • ability to send console.error to another Function while in production (for easier error management like sending an email)
  • using localStorage, a history is kept of all previous logs, limited to 100 ( configurable )
  • add a filter so that you only see the logs you want

Install

Via bower

1
$> bower install cross-console

Via NPM

1
$> npm install cross-console

Download Manually

  • Download the files using the GitHub .zip download option
  • Use either the compressed bin/cross-console.min.js or the lib/cross-console.js file.

Add a script path in your source

1
<script type="text/javascript" src="/bin/cross-console.min.js"></script>

Accessing the original console

Some consoles give useful information like timing and memory usage; so you still have access to that

Settings

To change from the default settings, just access the code via the window or root object. Notice that cconsole and console are interchangeable

1
window.cconsole.settings || window.console.settings

You can also change the settings by accessing the set function and passing an object of key:value pairs of the following.

1
2
3
4
5
6
7
window.console.set({
	"environment": "production",
	"debug": false,
	"notify":function(msg,identifier) {
		alert(msg,identifier);
	}
});

window.cconsole.settings.standBy

default false ( boolean )

Stand By will effectively turn off CConsole. It will act as if it was not even there.

window.cconsole.settings.debug

default false ( boolean )

Debug turns on all logs so that the console will light up with everything that is thrown at it.

window.cconsole.settings.environment

default production ( string: development || production )

This is the smartest addition to the code. Effectively, you can be in ‘development’ mode to be able to see all console.error and console.warn come through. If you are in production mode you will not see anything. If debug is on, it will overwrite this setting and allow everything to come through.

window.cconsole.settings.notify

default function(error, identifier) { return; } ( function )

You can overwrite this functionality in your own code. This function will be called for every console.error that occurs. This allows you to have a second set of loggin occur on that error, like a server backend to track them or graph them, etc.

  • error : this is the string that was given to console.error
  • identifier : this is intended to be a line item that is unique to this error, to make for easier debugging.

window.cconsole.settings.filterLog

default false ( string )

Allows the code to only show things in the console log that fit the filter that’s applied. Use the console.setFilter(string) to apply a filter and console.clearFilter() to remove the filter. It will not filter out errors or warnings

window.cconsole.settings.history

default 100 ( integer )

This is the length of the history that is kept. Having a large enough number for good use, and a low enough number to stop overgrowth is essential. History will perist in localStorage if JSON and storage is available, using the key CC.history

Examples

Basic changing of settings

1
2
3
4
5
6
7
8
9
10
11
12
window.console.warn('Will not show up due to defaults');
// Change to development and debug
window.cconsole.settings.environment = 'development';
window.console.warn('Warns will show up while in development');

window.cconsole.settings.debug = true;
window.console.log('Everything will show up in console');

window.cconsole.settings.standBy = true;
window.console.log('Actually just using the log if it`s there');

// window.cconsole.settings.history //> array of all of the above, except the last console log because standBy was turned on

Catching console.error in production

1
2
3
4
5
window.cconsole.settings.notify = function(error, key) {
 mailEngineers(error, key);
};

console.error('This should not have happened'); // runs notify -> presumably sends emails to engineers

Filtering out only the messages you expect to see

1
2
3
4
5
window.cconsole.setFilter('myfeature');

console.log('somefeature','this isnt showing');
console.log('myfeature', 'this is showing');
console.warn('this will always show up, so will errors');

You should try it out, see how it work for you and make sure to fork me on Github to improve it!