Better JavaScript — No Wrappers and ==

Like any kind of apps, JavaScript apps also have to be written well.

Otherwise, we run into all kinds of issues later on.

In this article, we’ll look at ways to improve our JavaScript code.

Avoid Primitive Wrappers

We should avoid primitive wrappers so that we don’t have to deal with issues with them.

So we should never have code like:

const s1 = new String("foo");  
const s2 = new String("foo");

Then if we have:

s1 === s2;

then it returns false since they’re different objects.

They are only good for call methods implicitly.

So if we have:

"foo".toUpperCase();

then the string is converted to a string wrapper object and then the toUpperCase method is called on it.

Because primitives can be wrapped with wrappers automatically, we can add properties to them.

For instance, we can write:

"foo".bar = 200;

But if we write:

"foo".bar

we get undefined .

The wrapping is done each time a property is added.

Once that’s done, then wrapped object is discarded immediately.

So we’ll never see the value that we set.

This is another place where JavaScript hide type errors.

Using == or != with Mixed Types

If we want to compare operands with different types, then we’ve to beware that the operands will be converted.

For instance, if w have:

const today = new Date();  
if (form.month.value == (today.getMonth() + 1) &&  
  form.day.value == today.getDate()) {  
  // ...  
}

then the types of the operands will be converted to numbers and compared.

It’s easy to miss the data coercion.

So it’s better to do the conversion explicitly by writing:

const today = new Date();  
if (+form.month.value == (today.getMonth() + 1) &&  
  +form.day.value == today.getDate()) {  
  // ...  
}

Now we know both sides have numbers.

Even better, we should use === instead of == for equality comparison so 2 things with different types will all be false .

So we write:

const today = new Date();  
if (+form.month.value === (today.getMonth() + 1) &&  
  +form.day.value === today.getDate()) {  
  // ...  
}

then we know the comparison will only be done with 2 numbers.

When 2 arguments have the same type, then there’s no difference between == and === .

But if the operands for comparisons are different types, we’ll run into problems.

The type coercion rules aren’t obvious.

They’re also complex.

Computers can’t read our minds, so == will probably use the wrong assumptions.

There are several rules for the == operator.

If the first operand is null and the 2nd is undefined then there’s no coercion.

If the first operand is null or undefined and the 2nd operand is anything other than null or undefined , then there’s no coercion.

If the first operand is a primitive string, number or boolean and the 2nd operand is the Date object, then the primitive is converted to a number.

The Date object is converted to a primitive by trying toString first, then valueOf .

If the first operand is a string, number, or boolean and the 2nd operand is a non-Date objecrt, then the primitive is converted to a number.

And the non-Date object is covert to a primitive by trying toString first, then valueOf .

If both operands are primitive string, number, or boolean, then they’re both converted to numbers.

We just use the === and forget about all these rules.

Conclusion

== or != doesn’t have much benefits and has lots of problems.

=== or !== is better.

Primitive wrappers should also be avoided.