18. Booleans and the Stricter === and !== Operators

While it’s polite to say that all types are interesting and fun to be around, you and I both know that is a lie. Some types are just boring. The boolean type is one such example. Here is the reason why. Whenever you initialize a variable using either true or false, you create a boolean:

var sunny = false;
var traffic = true;

Congratulations. If you know just this, you are 80% of the way there in fully understanding how booleans operate. Of course, 80% isn’t really adequate when you think about it. It’s like eating a hot dog without any condiments. It’s like watching a live concert and leaving before the encore set. It’s like leaving a sentence mid.

What I am going to expand upon a bit in this chapter is the other 20% made up of various boolean quirks; the Boolean object; the Boolean function; and the important === and !== operators.

var sunny = false;
var traffic = true;

Like you’ve seen so many times already, behind every primitive there is an Object-based representation lurking in the shadows. The way you create a new boolean Object is by using the new keyword, the Boolean constructor name, and an initial value:

Click here to view code image

var boolObject = new Boolean(false);
var anotherBool = new Boolean(true);

The initial values you can pass in to the Boolean constructor are commonly true and false, but you can pretty much pass anything in there that will result in the final evaluation being true or false. I will detail what kinds of values will predictably result in a true or false outcome in a little bit, but here is the obligatory warning from the Surgeon General about this approach: Unless you really REALLY want a Boolean object, you should stick with primitives.

Click here to view code image

var boolObject = new Boolean(arbitrary expression);

This is really advantageous because you may find yourself wanting to evaluate a boolean expression where the data you end up with isn’t a clean true or a false. This is especially common when you are dealing with external data or code, and you have no control over which of the various falsey and truthy values you get. Here is a contrived example:

Click here to view code image

var isMovieAvailable = getMovieData[4];

The value for isMovieAvailable is probably a true or false. When it comes to processing data, you often have no guarantee that something at some point will break or change what gets returned. Just like in real life, simply hoping that things will work is never adequate without you taking some actionable steps. The Boolean function is one such step.

Now, creating your own function to deal with the ambiguity may be overkill, but the downside with the Boolean constructor is that you are obviously left with a boolean object—which isn’t desirable. Fortunately, there is a way to get the flexibility of the Boolean constructor with the lightweightedness of a boolean primitive extremely easily. That way is led by the Boolean function:

var bool = Boolean(true);

The Boolean function allows you to pass in arbitrary values and expressions while still returning a primitive boolean value of true or false. The main difference in how you use it compared to the constructor approach is that you don’t have the new keyword. W00t! Anyway, let’s take a few moments and look at the variety of things you can pass in to the Boolean function, and note that all of this will also apply to what you can pass in to the Boolean constructor you saw in the previous section as well.

The values you can pass in to return false are null, undefined, empty/nothing, 0, an empty string, NaN, and (of course) false.

Click here to view code image

var bool;

bool = Boolean(null);
bool = Boolean(undefined);
bool = Boolean();
bool = Boolean(0);
bool = Boolean("");
bool = Boolean(NaN);
bool = Boolean(false);

In all of these examples, the bool variable will return false. To return true, you can pass in a value of true or ANYTHING that results in something other than the various false values you saw earlier:

var bool;

bool = Boolean(true);
bool = Boolean("hello");
bool = Boolean("Liam Neesons" + "Bruce Willie");
bool = Boolean(new Boolean()); // Inception!!!
bool = Boolean("false"); // "false" is a string

In these examples, the bool variable will return a true. That may seem bizarre given some of the statements, so let’s look at a few of the subtle things in play here. If what you are evaluating is an object, such as new Boolean(new Boolean()) the evaluation will always be true. The reason is that the mere existence of an object will trigger the true switch, and calling new Boolean() results in a new object. Extending this logic a bit, it means the following if statement actually results in a true as well:

Click here to view code image

var boolObject = new Boolean(false);

if (boolObject) {
    alert("Bool, you so crazy!!!");
}

It doesn’t matter that the object you are evaluating is secretly a false in disguise...or a String object or an Array and so on. The rules for primitives are more simple. If you are passing in a primitive (or something that evaluates to a primitive), anything other than null, undefined, 0, an empty string, or false will result in a result of true.

Here is an example:

Click here to view code image

function theSolution(answer) {
    if (answer == 42) {
        alert("You have nothing more to learn!");
    }
}

theSolution("42"); //42 is passed in as a string

In this example, the expression answer == 42 will evaluate to true. This works despite the 42 you are passing in being a string and the 42 you are checking against being a number. What is going on here? In what kind of a world is a string and a number equal? With the == and != operators, this is expected behavior. The value for the two things you are comparing is 42. To make this work, JavaScript forces the two different yet similar values to be the same under the hood. This is formally known as type coercion.

The problem is that this behavior can be undesirable—especially when this is happening without you knowing about it. To avoid situations like this, you have stricter versions of the equality and inequality operators, and they are === and !== respectively. What these operators do is that they check for both value and type and do not perform any type coercion. They basically force you to write code where the burden on ensuring true equality or inequality falls squarely on you. That is a good thing™.

Let’s fix our earlier example by replacing the == operator with the === operator:

Click here to view code image

function theSolution(answer) {
    if (answer === 42) {
        alert("You have nothing more to learn!");
    }
}

theSolution("42"); // 42 is passed in as a string

This time around, the conditional expression will evaluate to false. In this stricter world, a string and number are of different types despite the values being similar. Because no type coercion takes place, the final result is false.

The general word on the street is to always use the stricter forms of the equality and inequality operators. If anything, using them will help you to spot errors in your code—errors that might otherwise turn out very difficult to identify.