Exploring HTML5's localStorage - Persistent Client-Side Key-Value Pairs

The other day, when building the Things I Give website and web app, I used HTML5's localStorage object for the first time. Like cookies, the localStorage object provides a way to persist string-based, key-value pairs on the client. Unlike cookies, however, these values don't have to be passed back to the server with every request. And, the localStorage has a much larger quota than cookies - about 5 megabytes on supporting browsers.

The localStorage object has four primary method:

• localStorage.clear()
• localStorage.getItem( key )
• localStorage.removeItem( key )
• localStorage.setItem( key, value )

When dealing with the localStorage object, it is important to remember that, like cookies, you are dealing with string values. Both the key and the value arguments must be strings. And, while the browser might not throw an error if you pass-in non-string values, you'll quickly find that it is simply calling the toString() method implicitly.

So, how persistent is the localStorage? To be honest, I have no idea. Other than calling the .clear() method explicitly, I am not even sure how to clear the localStorage at the browser level. If anyone has any insight on this matter, I'd love to hear it.

That said, let's take a quick look at the localStorage object in action:

As you can see, I am using various approaches to testing, setting, and retrieving data from the localStorage object. And, when we run the above code, we get the following console output:

hella in localStorage --- false
localStorage.getItem( 'hella' ) --- null
hella in localStorage --- true
localStorage.getItem( 'wicked' ) --- awesome
typeof( myObject ) --- string
hella in localStorage --- true null
wicked in localStorage --- false null

The first thing I do is start off by testing the existence of the key, "hella." While the localStorage object does present accessor methods, it can also be used like an associative array. So, while I am using the getItem() to check for a null-return, I am also using Javascript's "in" operator to check for key existence.

Once set, you can see that both the "in" operator and the getItem() method check for the existence of and the value for the given key, respectively. Notice also, however, that the return value is always a string. Even after we set a Object instance, its value comes back as the toString() representation of that object. Remember: we are always dealing with string values!

Now look at the last couple of lines. I am using both the "delete" operator and the removeItem() method to delete keys from the localStorage object; but, when we follow that up with subsequent tests, you can see that the "in" operator no longer returns a valid result. In our case, it tells us that the key, "hella" still exists within the localStorage object even though its return value is null (ie. the value doesn't exist).

localStorage is definitely cool; but, it has some limitations. As such, it might be useful to think of localStorage more like a "behavior." Then, we can build other objects that use the localStorage as an encapsulated "storage behavior." In the following demo, I've done just that; I've created a Cache object that uses the localStorage internally, but provides a more flexible interface:

The Cache object has a smaller interface than the localStorage object, providing no associative-array aspect. But, in addition to a hasItem() method, it also provides for non-string values and a default get-value:

• Cache( storage, serializer )
• Cache.clear()
• Cache.getItem( key [, defaultValue ] )
• Cache.hasItem( key )
• Cache.removeItem( key )
• Cache.setItem( key, value )

When we create the cache object, we need to pass a storage container and a serialization behavior to the constructor. This is because we don't want to limit our cache interactions to those that deal with string values. We want to be able to pass a variety of objects to the cache and have the cache worry about the string-based serialization and deserialization.

In this demo, we are using the localStorage object as our storage container and the native JSON object as our serialization behavior. And, when we run the above code, we get the following console output:

cache.hasItem( 'girl' ) --- false
cache.setItem( 'girl', girl ) --- Object { storage=, serializer=JSON}
cache.hasItem( 'girl' ) --- true
cache.getItem( 'girl' ).name --- Tricia

As you can see, our complex "girl" object was successfully set, serialized, deserialized, retrieved, and then accessed. At the end of this workflow, we were able to get the "name" property of the duplicated object.

The localStorage object looks like it has some very cool potential as far as a client-side persistence mechanism goes. This is really my first look into it, so I am sure there is a lot more to wrap my head around. Hopefully, I'll have more to say on this shortly.

You Might Also Be Interested In: