Should I use an empty property key?

Question

I've tested this only in Firefox, but apparently you can use an empty string as a key to a property in an object. For example, see the first property here:

var countsByStatus = {    "": 23, //unknown status   "started": 45,   "draft": 3,   "accepted": 23,   "hold": 2345,   "fixed": 2,   "published": 345 } 

In skimming through the EcmaScript specs, it appears that (at least in 5), property keys are defined as strings, and strings as 0 or more characters. This implies that an empty string is a valid property name according to the specs.

Anyway, I'm tempted to use this in a section of code where I'm calculating summaries of some counts by the status of a data item (similar to what I've shown above). There are some items which might not have a status, and I need a placeholder for those. Since statuses are user-definable, I don't want to risk using a dummy word that might conflict.

It seems so simple and elegant, in looking at the data I can easily tell what the blank string would mean. It also makes the code a little bit more efficient, since the empty string would be the exact value of the status in the items without a status.

But at the same time, my instincts are telling me that something is wrong with it. I mean, apart from the chance that some browser might not support this, I feel like I've encountered a bug in JavaScript that will be fixed some day. But, at the same time, that's the same feeling I once had about a lot of other JavaScript features that I now use every day (such as the time I discovered that && and || returns the value of one of the operands, not just true or false).

Answer 1

An object's key must be a string, and the empty string ('') is a string. There is no cross browser issue that I've ever come across with empty strings, although there have been very few occasions where I thought it was acceptable to use an empty string as a key name.

I would discourage the general usage of '' as a key, but for a simple lookup, it'll work just fine, and sounds reasonable. It's a good place to add a comment noting the exceptional circumstance.

Additionally, during lookup you may have issues with values that are cast to a string:

o = {...} //some object foo = 'bar';  //some examples o[foo] //will return o['bar'] o[null] //will return o['null'] o[undefined] //will return o['undefined'] 

If you'd like to have null and undefined use the '' key, you may need to use a fallback:

key = key || ''; 

If you might have non-string values passed in, it's important to cast too:

key = key || ''; key = '' + key; 

note that a value of 0 will turn into '', whereas a value of '0' will stay '0'.

---

In most cases, I find I'm picking a pre-defined value out of a hashtable object. To check that the value exists on the object there are a number of options:

//will be falsey if the value is falsey if (o[key]) {...}  //will return true for properties on the object as well as in the prototype hierarchy if (key in o) {...}  //returns true only for properties on the object instance if (o.hasOwnProperty(key)) {...}