My JavaScript book is out! Don't miss the opportunity to upgrade your beginner or average dev skills.

Sunday, June 24, 2012

The JavaScript typeof Operator Problem

TL;DR don't even try to normalize or shim newer typeof via code: you simply can't!

Whenever it was a mistake or not to consider typeof null == "object", many libraries that tried to normalize this operator failed to understand that null is not the only problem.

The JS Polymorphism Nature

We can borrow methods for basically everything but primitives values, such booleans, numbers, and strings, do not accept indeed any sort of property or method attached runtime.

var s = "hello";
s.greetings = true;
alert(s.greetings);
// "undefined"

However, we can still use methods through call() or apply():

function isGreetings() {
return /^(?:ciao|hello|hi)$/.test(this);
}
alert(isGreetings.call("hello"));
// true

The only way to find a method in a primitive value is to extend its own constructor.prototype:

String.prototype.isGreetings = function () {
return /^(?:ciao|hello|hi)$/.test(this);
};
alert("hello".isGreetings());
// true


What Happens When We Invoke A Method

In ECMAScript 3 up to 5.1, when "use strict" directive is not in place, any primitive value will be temporarily converted into an object, where only null and undefined will be converted into the original global object.

alert(function () {
return this === window;
}.call(null));

// ... and here a tiny winy problem ...
alert(function () {
return this ? true : false;
}.call(false)); // true
alert(function () {
return Boolean(this);
}.call(false)); // true
alert(function () {
return !!this;
}.call(false)); // true

Back to the previous chapter, a situation like this might mislead as well:

function setAsGreetings() {
this.greetings = true;
alert(this.greetings); // true
}
var s = "hello";
setAsGreetings.call(s);
alert(s.greetings); // undefined


Why This Is A Problem

Try to imagine this really simple piece of code:

function whichType() {
return typeof this;
}
// guess what ...
alert([
whichType.call(null), // "object"
whichType.call(false), // "object"
whichType.call(true), // "object"
whichType.call("hello"), // "object"
whichType.call(123), // "object"
whichType.call(undefined) // "object"
].join("\n"));

Now you can play adding "use strict" to the very beginning of the whichType function.
Doing the same with an argument, rather than context injection, will produce the same output, regardless the function has or not the strict directive.

function whichType(o) {
// pointless "use strict";
return typeof o;
}
// guess what ...
alert([
whichType(null), // "object"
whichType(false), // "boolean"
whichType(true), // "boolean"
whichType("hello"), // "string"
whichType(123), // "number"
whichType(undefined) // "undefined"
].join("\n"));


What If You Want Use new String/Number/Boolean

It's not only about context injection and the typeof this, it's also about the ability to use collections of the same type as we need.
As example, let's imagine we have a list of unique IDs, and we would like to flag them, relate them, or use them, as objects.

var ids = [
"a",
"b",
"c"
];

// an easy way to mirror strings as objects
var flagged = ids.map(Object);

// check if a generic input/id exists ...
var i = ids.indexOf("b");

// ... and check if it has been used/touched already
if (-1 < i && !flagged[i].touched) {
flagged[i].touched = true;
alert("touched");
}
// once again ... but it will never happen
if (-1 < i && !flagged[i].touched) {
flagged[i].touched = true;
alert("touched");
}

With above example we might use the variable ids to simply filter existent and not existent input, and mirror these ids through they respective objects and eventually reuse these objects as we need, concatenating them, recycling them, etc etc ... I know, above example is not such common use case, right? But of course it's not since we have so many problems with typeof and nobody in JS world has ever suggested to use, when necessary, these constructors in a useful way...

typeof In JS.Next

Since explicit should superset implicit behaviours, ECMAScript 6 and code under "use strict" directive will react like this.

function app(s) {"use strict";
alert(type.call(s));
}

function type() {"use strict";
return typeof this;
}

app("primitive"); // "string"
app(new String("object"));// "object"

This is actually awesome since we can always tell if that string/object has been created using new Constructor or not ... which leads with less ambiguous code and the possibility to use objects as primitives whenever we find a case were it's needed.

function setGreetings() {
this.greetings = true;
}
var s = "hello";
setGreetings.call(s); // pointless
s.greetings; // undefined

// but if we want ...

s = new String(s);
setGreetings.call(s);
s.greetings; // true !!!

As summary, knowing in advance how an object has been created, will let us understand if whatever property/method changed or attached to a generic this will make sense or not ... unless these operations are not simply used internally during the temporarily lifetime of that possible object ... where again we might need to know if we have to clean up after or not ... that's what I call control, isn't it?

... And No Polyfill Will Do

Bad news here is ... there is no way to replicate the new and correct behaviour of the next typeof operator.
If we remove "use strict" directive from the latter example's type() function, we'll notice that the result will be "object" in both cases ... no matter how we pass the original argument.

Reasonable + Inconsistent = Fail

If your only concern is that typeof null should produce the string "null", you might realize that o === null is all you need, rather than creating and calling a function every time you want/need to understand the type of an object.
As we have seen before, when null is used as context, the typeof could return "object" in any case.
When latter case happens, the check against the triple equality operator will fail as well.
If null is not the only problem, just consider that if an engineer created a variable using new String(text) rather than using just text there must be a bloody reason: either the engineer does not know JavaScript OR, most likely, decided to use the possibility offered by an object that is wrapping a primitive value.
If you use a framework that does this wrapping by default there's only one thing to do: change framework!
Strings are immutable while Objects are always freshly baked ... since a list of strings as objects cannot even use Array#indexOf unless you don't hold and/or compare via Generic#valueOf() every time the list content, the amount of pointless RAM and CPU used to work with these kind of wrappers does not scale ... full stop.
If you never use new String and believe that nobody else will as well, your logic might be screwed in any case by the fact that newer browsers might implement a proper typeof and make your code/logic weak when the original constructor has been used as wrapper.

How To Migrate, How To Not Fail

Unless both your code and your environment is frozen by respective versions, and it does not matter if it's client or server side, you cannot basically trust your own code because one day, in some browser, it might act differently.
If you need typeof so much and your code is for 3rd parties development, you might decide to create two slightly different versions of your code or simply normalize the old typeof behavior forgetting then returning "string" when you don't actually know if the developer meant string or new String.
A feature detection like this one could help:

var NEW_TYPEOF = function(){
"use strict";
return typeof this == "string";
}.call("");

To simplify above code you might trust the generic strict directive behaviour, through undefined, via this snippet:

var USE_STRICT_COMPATIBLE = function(){
"use strict";
return !this;
}();

Followed by the rarely seen check:

var USE_STRICT_ENABLED = function(){
return !this;
}();

Above check does not simply tell us if the the browser can handle the strict directive, it also tells us if we are already under use strict.
If we wrap everything in our own closure we might not care in any case ... so, back to the topic, we might understand through these checks if we are under strict directive but what we cannot normalize in any case is something like:

function borrowedMethod() {
alert(yourTypeOfShim(this));
}
borrowedMethod.call("fail");
borrowedMethod.call(new String("fail"));

In ECMAScript 3rd Edition latest snippet will return "object" while in ES5 and strict directive it will return "string".
If your normalizer is "so cool" that transform any instanceof String into "string", then you might realize that same code run under strict in ES5 will return "object" so either both ways, and as summary, your function is not reliable.
Can we say now there's more mess than before? Oh well ...

Doesn't Matter, Had Type

If you wanna have a function that will never be able to compete with the real power of ES6 or "use strict" typeof operator, you might end up with something like this:

function type(o) {"use strict";
var type = typeof o;
if (type == "object") {
if (!o)
type = "null"
; else if (
o instanceof Boolean ||
o instanceof Number ||
o instanceof String
)
type = typeof o.valueOf()
;
}
return type;
}

However, all you gonna have in this case is a function that removes a new feature from the next version of JavaScript.
I have aded this script just to give you a chance if you wanna believe that using methods across primitive wrappers does not make sense ( subclassing anybody ? at that point you gonna have another problem ... oh well, again ... )

13 comments:

Anonymous said...

What about the ever handy and reliable Object.prototype.toString method ?

var rtypeof = (function(){
var toString = Object.prototype.toString
return function(o){
return toString.call(o).match(/\[object\s(.*)\]/)[1].toLowerCase()
}
}())

Andrea Giammarchi said...

you gonna have a freaking slower function plus it won't solve the problem with primitives VS primitives wrappers ... so I am not sure how useful it is in this case

Anonymous said...

It's only a quick example of something doable with Object.prototype.toString.

It could be used in many hard-to-beat-faster ways depending on what you need at a given moment.

I think it was worth mentioning ;-)

Anonymous said...

What do you think about https://github.com/bestiejs/spotlight.js/blob/13cc67d0239787d3c86a0f5b4cf02189bf57bc9c/spotlight.js#L266-300?

Andrea Giammarchi said...

that would not solve the problem about string VS String so is something different from typeof introduced in ES6

As I have said, unfortunately there is no way to understand how a variable has been created in ES3 so no polyfill will work as expected.

If the [[Class]] is what you need then that function you suggested looks robust but way too slow for most common case, imho

Anders Ringqvist said...

Andrea, that instanceof solution wouldn´t work with values from another window, would it? Isn´t it the same age old problem as with the non native isArray function? Object.prototype.toString seems to be the only silver bullet proof way but as you say, it´s slow. But working slow beats non working fast.

Anonymous said...

Pretty great post. I just stumbled upon your weblog and wanted to mention that I've really loved surfing around your weblog posts. In any case I will be subscribing in your rss feed and I'm hoping you write again soon!

PoIuYt

Irishka said...

the typeof operator problem within call method without strict mode? emm... rtm?


Method of Function
Implemented in JavaScript 1.3
ECMAScript Edition ECMAScript 3rd Edition
Syntax

fun.call(thisArg[, arg1[, arg2[, ...]]])
Parameters

thisArg
The value of this provided for the call to fun. Note that this may not be the actual value seen by the method: if the method is a function in non-strict mode code, null and undefined will be replaced with the global object, and primitive values will be boxed...


regards

Andrea Giammarchi said...

Irishka have you read the post at all or you are just trolling? I wonder if you got what is this post about ... please read again carefully, the fact primitives will be boxed is not new since IE4 ... but thanks ...

Irishka said...

Andrea, I'm not trolling,

I'm wondering, why you are expecting typeof object, to be something else as object?

Due to ECMA5 Spec, so 6 draft: Object (native and does not implement [[Call]]) is "object"). = so it is expected behavior, the other thing that you wish to get an object description instead.

Andrea Giammarchi said...

again ... this post is about the different behavior between ES3 and ES5 where latter one cannot be emulated because:
"why you are expecting typeof object, to be something else as object?"

exactly what happens in ES5 with "use strict"

I suggest you to *read* at least the "typeof In JS.Next" chapter so you'll see that typeof this is *not* an object ... unless I completely missed your point ...

br

Irishka said...

the behavior of typeof operator was not changed since ES3 - there are no differences.

The different behavior between ES3 and ES5: in the strict mode, a this value is not automatically coerced to an object. The typeof operator behaves appropriately.

My point - the operator typeof doesn't fail and will not behave in different way in strict mode.

regards

Andrea Giammarchi said...

P.S. I understand your point about "not being typeof different but the `this` context one" but the problem is that typeof is the only operator able to retrieve the "type" of a variable, as primitive or object.

Since this is the only way to retrieve something like "string" rather than "object" ... using the same code with "use strict" or not, THE SAME CODE, can produce different output THROUGH typeof because of the new ES.Next behavior with objects ... how do you know there is a new behavior and you are in "use strict" ?

Only with typeof operator ... got it? typeof is fine, but being the only thing usable to understand the "type of" is not fine anymore and is NOT SHIMMABLE in ES3 or ES5 without "use strict"

Hope now is clearer ... hope!