One of my favourite proposals in ECMAScript Harmony is Weak Maps. Simply put, ‘weak maps are unordered tables mapping objects to values’ with references to those objects and values being weak. A weak reference means that the item won’t be protected from garbage collection if no other references are held. For example:
// Using the proposed API (currently implemented in Firefox)
var wm = WeakMap();
(function () {
var obj = {};
wm.set(obj, 1);
})();
console.log(wm); //-> "[object WeakMap]"
By now a very obvious use case might have occurred to you, but I’ll get to that in a minute. When the above function finishes execution, obj is no longer reachable, so it can be garbage collected even though our WeakMap object is still reachable. This addition to the language is a useful tool for an age-old concern in JavaScript and the DOM; memory leaks. That aforementioned use case is becoming more obvious now, eh?
Where do Weak Maps fit in with current code?
OK, if you never had to implement this kind of thing before, you might not have thought of jQuery’s data() method. jQuery.data() allows us to attach an arbitrary value to a DOM object. Whilst you can do this with expando properties, ordinarily you run the risk of circular references and memory leaks. jQuery tackles this by creating a unique ID for itself (only once) and each element it is attaching data to. It tacks the element’s unique ID, which is really just an incremented counter, onto an expando property whose name is the unique ID. So it looks something like this:
element[jQuery.expando] = elementId;
Any data you attach to the element is actually stored in an array at index elementId. jQuery is able to avoid memory leaks because there are no circular references, and it can delete all stored data when the page is unloaded (or the element is removed using jQuery’s own methods). However, it does have some limitations. For example — according to the source code — object/embed/applet cannot accept expando properties and, therefore, jQuery.data() cannot work with them.
Weak maps come in here because they can do the job much better. They cut out the need for the expando property entirely, along with the requirement of handling JS objects differently to DOM objects. They also expand on jQuery’s ability to allow garbage collection when DOM elements are removed by its own methods, by automatically allowing garbage collection when DOM elements no longer reachable after they’ve been removed by any method. Had WeakMaps been implemented in ECMAScript 3 (if only), jQuery’s workload with data() could have been significantly reduced. Perhaps jQuery wouldn’t have bothered implementing data if we could create weak maps, though.
Another use case to consider is secretly extending objects without the danger of naming collisions. Using someGloballyAvailableObject.someProperty = "some arbitrary value"; as an example, what if someGloballyAvailableObject already has someProperty? We’ve just written a potentially script-breaking piece of code. However, with a weak map we can eliminate this danger entirely:
(function () {
var wm = new WeakMap();
wm.set(someGloballyAvailableObject, {someProperty:"some arbitrary value"});
})();
There’s also a hidden bonus here. I used the word secretly before because no other piece of our script can access this mapped value if we never expose the wm variable.
You might recall (if you read it) my article on creating lookup lists. If you do, you might be thinking that weak maps are a good use for creating lists, but in reality this isn’t the case because weak maps — in the current proposal, at least — will only map a value to an object.
Weak map compatibility shims
A true weak map is technically impossible in ECMAScript 3. We can create a map of objects to values by simply using two arrays:
function WeakMap() {
this.keys = [/* key01, key02, key03 */];
// ↓ ↓ ↓
this.vals = [/* val01, val02, val03 */];
}
Unfortunately, there’s 2 very important caveats here. Firstly, these references are not (and cannot be) weak, so they will not be garbage collected as long as the mapping exists. Secondly, for our get(key) method to work, we need to search our keys array. This significantly impacts performance, particularly on large maps.
As for ES5, I was pointed in the direction of this implementation recently. It’s very clever; It eliminates the need for a keys array and uses a custom valueOf function to keep track of the mapped value. I profiled the method in Chrome and it does indeed appear to prevent leaks. However, it does still have its limitations like not working on frozen objects or objects whose valueOf function is not configurable.