{"id":817,"date":"2011-09-24T17:52:03","date_gmt":"2011-09-24T17:52:03","guid":{"rendered":"http:\/\/kera.name\/articles\/?p=817"},"modified":"2011-09-24T18:00:21","modified_gmt":"2011-09-24T18:00:21","slug":"a-brief-introduction-to-javascript-objects-arrays","status":"publish","type":"post","link":"https:\/\/kera.name\/articles\/2011\/09\/a-brief-introduction-to-javascript-objects-arrays\/","title":{"rendered":"A Brief Introduction to Javascript Objects & Arrays"},"content":{"rendered":"

(tl;dr:<\/strong> Object<\/code>s are {}<\/code> and Array<\/code>s are []<\/code>; use string keys and for .. in<\/code> only with Object<\/code>s.)<\/sub><\/p>\n

\n

Having come up against disbelievers too often now, I've decided to take matters into my own hands and definitively conclude this argument once and for all.<\/p>\n

Arrays may not<\/strong> have string keys.<\/em><\/p>\n

Take the following oft-seen pattern:<\/p>\n

var myArray    = new Array();\nmyArray['foo'] = 'lol';\n\/\/ an array with one element?<\/code><\/pre>\n
This is wrong<\/strong>. Broken. Bad, wrong, invalid. Naughty. And constantly misunderstood.<\/p>\n
\n
Objects<\/h2>\n
The issue stems from both terminology and misleading language design. Pretty much everything in Javascript is an object<\/em>, and those that are not objects — the primitive types like integers, booleans and strings — all have object-type counterparts. This is even true for functions!<\/p>\n
At its most basic, a Javascript object is a collection of key\/value pairs. We can create our own typeless object instance using {}<\/code> notation (syntax from which the JSON data format is derived, incidentally):<\/p>\n
var myObj = {\n   'foo': 1,\n   'bar': 2\n};<\/code><\/pre>\n
We could also build up the properties individually, using obj[x]<\/code> notation:<\/p>\n
var myObj    = {}; \/\/ `new Object()` would do, too\nmyObj['foo'] = 1;\nmyObj['bar'] = 2;<\/code><\/pre>\n
This notation looks like "array" access notation due to the influence of other major programming languages and, in fact, this basic key\/value functionality is more generally known as a "map" or… an "associative array". This is only a general<\/em> term, though, because in Javascript they are just "objects".<\/p>\n
Why does this terminology matter? It matters because Javascript has confused matters by providing functionality for a stricter subset of the "array" concept: the numerically-indexed Array<\/code> type.<\/p>\n
\n
Arrays<\/h2>\n
Introduction<\/h3>\n
The Array<\/code> type is a specialisation of objects that provides an element access API (.push<\/code> and .length<\/code>) and maintains numeric, sequential keys for you:<\/p>\n
var myArray = []; \/\/ `new Array()` would do, too\nmyArray.push('house');\nmyArray.push('bird');<\/code><\/pre>\n
Or, again, we can do this in one push:<\/p>\n
var myArray = ['house', 'bird'];\n\nfor (var i = 0; i < myArray.length; i++) {\n   console.log(myArray[i]);\n}\n\/\/ Output: \"house\" \"bird\"<\/code><\/pre>\n
Notice how you still access the array's elements using the obj[x]<\/code> notation. That's because the Array<\/code> stores its elements as properties in itself, alongside the various other properties that it needs in order to function (like length<\/code> and push<\/code>, plus any other implementation-defined internal properties).<\/p>\n
Looping over properties<\/em> not elements<\/em><\/h3>\n
However, this is also why looping through an Array<\/code> with for .. in<\/code> syntax is wrong<\/em> -- for .. in<\/code> loops through low-level object keys<\/em>, not the \"elements\" of this higher-level \"array\" abstraction:<\/p>\n
var myArray = ['house', 'bird'];\nfor (var key in myArray) {\n   console.log(myArray[key]);\n}\n\/\/ Possible output: \"bird\" \"concat\" \"every\" \"filter\" \"forEach\"\n\/\/                  \"house\" \"indexOf\" \"join\" \"lastIndexOf\"\n\/\/                  \"length\" \"map\" \"pop\" \"push\" \"reduce\"\n\/\/                  \"reduceRight\" \"reverse\" \"shift\" \"slice\"\n\/\/                  \"some\" \"sort\" \"splice\" \"unshift\"<\/code><\/pre>\n
In fact, recent implementations of Javascript handle this more intelligently and will still output just 'house' 'bird'<\/code> for the above loop (*), but you cannot and should not rely on this behaviour.<\/p>\n
Array holes<\/h3>\n
Another issue is that, due to some magic, setting myArray[5]<\/code> will automatically increase length<\/code> along with it. However, this can cause \"holes\" to \"appear\" if you use object loop syntax:<\/p>\n
var myArray = [\"hello\"];\narr[100]    = \"goodbye\";<\/code><\/pre>\n
Now myArray<\/code> has a length<\/code> of 100, but we only set two user-defined properties in the underlying object representation. Using for .. in<\/code> will yield two indexes, while the for<\/code> loop will yield 101 indexes, where the 99 new numeric ones have an undefined<\/code> value. Which one did you intend?<\/p>\n
\n
The Misunderstanding<\/h2>\n
Unfortunately, browser vendors aren't helping to stem the spread of the myth that objects and arrays can or should be used in the same way.<\/p>\n
In addition to the for .. in<\/code> trickery mentioned above (*), the order of enumeration even on Array<\/code> objects is the order in which the properties were created:<\/p>\n
var array = [];\narray[2] = 'c';\narray[1] = 'b';\narray[0] = 'a';\n\nfor (var p in array) {\n   \/\/ p will be 2, 1 then 0 on IE <= 8\n}<\/code><\/pre>\n
This behaviour makes it quite obvious that the usage isn't quite right, but since Internet Explorer 9 the browser will enumerate the keys in ascending order, only serving to help propagate the myth that this is the right way to do things.<\/p>\n
Non-integer keys<\/h3>\n
Another oft-seen chunk of code looks like this:<\/p>\n
var myArray    = [];\nmyArray[\"foo\"] = 42;\nmyArray[\"bar\"] = 84;\n\nconsole.log(myArray[\"foo\"]);\n\/\/ Output: \"42\"<\/code><\/pre>\n
Argh! Now the programmer has created an Array<\/code>, but is using functionality of its underlying existence as an Object<\/code><\/em> instead of the proper API tools. In particular, he or she is setting object properties<\/em>, bypassing the Array<\/code> functionality completely.<\/p>\n
It appears to work, because we can still use myArray[x]<\/code> to access object properties: this hasn't changed. But we're completely bypassing the fact that this object is, more specifically, of type Array<\/code>.<\/p>\n
Now, because the above-described \"intelligent\" behaviour of some browsers works by explicitly ignoring only those object properties that it knows to be properties of the Array<\/code> prototype, when we loop over object properties we still only see those that we think we set:<\/p>\n
var myArray    = [];\nmyArray[\"foo\"] = 42;\nmyArray[\"bar\"] = 84;\n\nfor (var key in myArray) {\n   console.log(myArray[key]);\n}\n\/\/ Output: \"42\" \"84\"<\/code><\/pre>\n
But it's still not correct<\/a>, which we only actually notice when we use a proper Array<\/code> loop and notice that .length<\/code> has no idea what's going on. And how could it? It's a number.<\/p>\n
var myArray    = [];\nmyArray[\"foo\"] = 42;\nmyArray[\"bar\"] = 84;\n\nfor (var i = 0; i < myArray.length; i++) {\n   console.log(myArray[i]);\n}\n\/\/ Output: (nothing)<\/code><\/pre>\n
So, **we shouldn't be looping over Array<\/code>s with for .. in<\/code>.<\/p>\n
It also doesn't help that many reference materials (example<\/a>) continue to insist upon using the terms \"array\" and \"object\" interchangeably, and the difference between Array<\/code> and \"associative array\" (i.e. Object<\/code>) is not at all clear from the terminology.<\/p>\n
At least the Mozilla documentation makes this clear<\/a>:<\/p>\n
\n
An array is a JavaScript object. Note that you shouldn't use it as an associative array, use Object instead.<\/p>\n<\/blockquote>\n
\n
How to do it properly<\/h2>\n
It's tempting to rely on the above magical browser behaviours anyway. \"for .. in<\/code> lets us use string keys where for i < .length<\/code> does not, so let's just use for .. in<\/code>, right?\" Wrong.<\/p>\n
We shouldn't be using string keys in the first place.<\/strong><\/p>\n
So, in conclusion:<\/p>\n