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)) {...}