Never let stray errors in the console

When doing web development I fix all the errors that show up in the console. Often they don’t seem to impede the actual use of the software, but nevertheless I think it’s a good practice to fix them all. This following example should illustrate why.

I was doing some maintenance on an Angular project at work. I noticed that there were a couple of errors showing up in the console, but the web site still worked great, even with the errors.

The reason I was working on this project was because of a bug that was reported by QA. There was a display error that was happening and it was related to animations that were used in the Angular transitions, these are used when switching from one component to another. The error manifested itself with Android phones and iPhones. This bug probably slipped by because everything was working fine on desktop browsers.

After investigating, I saw that there was an error in the console about calling a property on undefined. On a view, this can be fixed using the ?. operator. The view used the ?. operator elsewhere but there was one place it was missing. I was sure this couldn’t be what was messing up the display of the animated transition.

I searched and searched but couldn’t find the problem.

So I decided that while I was there, I might as well fix this error that showed up in the console. I changed the . operator for ?. and lo and behold this also fixed the display problem.

By correcting it, it also corrected the other problem, which was probably caused by having an error during the Angular rendering.

This example demonstrates that you should never let console errors live, even if they don’t seem to have any negative effect on the web site.

JavaScript tip: format console.log output

You can format the output of console.log() using CSS. Use %c in your console log string and then add an argument for the CSS.

Here’s a simple script that uses CSS formatting to make a formatted console logger:

const fl = {
  log: function (title, message, color) {
    console.log('%c%s:%c %s', 
      `color: ${color}; font-weight: bold; text-decoration: underline ${color}`,
      'color: black',
      title, message);
  },

  info: function (message) {
    this.log('Info', message, 'green');
  },

  warning: function (message) {
    this.log('Warning', message, 'orange');
  },

  error: function (message) {
    this.log('Error', message, 'red');
  }
};

 

Here is the result in the console:

console formatting

JavaScript tip 4: use let and const

ES6 (aka. ECMAScript 2015, 6th edition) introduced the let and const statements.

These are meant as alternatives to var and baring browser compatibility issues, I recommend that you should be using them over var.

Speaking of browser compatibility, modern browsers support them, the main pain point being IE version 10 and older. Sadly some of us (ahem… yours truly) still sometimes work on intranet applications that must support older browsers so I mention it.

The difference between let and var is that let is scoped to the current scope (function, block, expression) while var is scoped to it’s containing function or barring that globally.

Here are some examples of behaviour which people not used to var‘s scoping might find odd:

function test1() {
  var foo = 1;

  if (true) {
    var foo = 2;
  }

  console.log(foo);  
}

test1();

function test2() {
  let foo = 1;

  if (true) {
    let foo = 2;
  }

  console.log(foo);  
}

test2();

Here test1() returns 2 even though the second foo declaration was in an inner scope. test2() on the other hand returns 1 has the second foo is scoped to it’s containing if statement.

Here is another example:

function test3() {
  for (var i = 0; i < 10; i++) {
    var inner = i;  
  }
    
  console.log(inner);
}

test3();

function test4() {
  for (let i = 0; i <= 10; i++) {
    let inner = i;  
  }
  
  console.log(inner);
}

test4();

In test3(), the output is 9 which is the last value of i in the loop’s inner scope. test4() returns an inner is not defined error which is more appropriate.

const scoping rules work like let but:

  • You must assign a value at declaration
  • You cannot re-assign a new value later on

This behaviour is similar to readonly and const in other languages like C# and affords an extra level of security for values that cannot change.