Among the myriad of axioms, HTML5 has a very specific mantra - Mobile/Offline first. Building mobile/offline first web-apps have always been irksome, given the stripped down memory and processing strengths of mobile devices and the end user's craving for luxury or ease of use. Surprisingly, HTML5 takes care of most of these legitimate demands. There are a couple of APIs which are noteworthy in this regard:
This article will focus on WebStorage API (Client-Side Storage).
History
It isn't the case that web developers are oblivious to the concept of client-side storage. HTTP Session-Cookies have always been the loyal servant. They have been primarily used to store server side information on the client. However, if I could jot down the shortcomings of cookies:
Turn the tables
Enter WebStorage. It's a specification which could be (arguably) concluded as the successor of cookies. It provides persistent storage as well as storage with expiration time. It has a larger size limit (upto ~5MB). It is a key-value store. Typical use cases could include storing friends list or an online music player playlist etc. on the client which doesn't demand frequent updates or server round-trips.
WebStorage specification has 2 major APIs, each of which provide access to a list of key/value pairs. Though the access APIs are fairly simple, they are synchronous. Keys in these lists are strings.
Usage:
if(window.localStorage){ //check for support
localStorage.setItem(key, value); //set a key/value pair in the list
var item = localStorage.getItem(key); //get the value for a particular key
localStorage.removeItem(key); // delete a key from the list
localStorage.clear(); // clear the entire list
}
The setItem method must check if a key/value pair with the given key exists or not. Further, if does, then the corresponding value is updated with the new value provided. However, in case of an exception wherein the value for the key could not be set, then the method throws a QuotaExceededError exception. It's a better practice placing them in try/catch blocks:
try {
localStorage.setItem(key, value);
}
catch(e) {
if(e.name === 'QUOTA_EXCEEDED_ERR') {
//quota exceeded
}
}
2. sessionStorage - this API is almost identical to the localStorage except that the data stored have a expiration time. The data stored in the sessionStorage object are active only in the current session.
Usage:
if(window.sessionStorage){ //check for support
sessionStorage.setItem(key, value); //set a key/value pair in the list
var item = sessionStorage.getItem(key); //get the value for a particular key
sessionStorage.removeItem(key); // delete a key from the list
sessionStorage.clear(); // clear the entire list
}
Web Storage Events
Whenever data is set/retrieved from the web storage object, a storage event is fired on the window object which we can be listen to.
window.addEventListener('storage', function(evt){
//do whatever is necessary
}, false);
Support
Browser support could be found here: link
Gotchas
The simplicity of the API comes at a price. The price is paid when complex or substantially large data is stored in the WebStorage objects:
Conclusion
In my opinion, Web Storage fares well while storing insensitive data on the client or data which do not need frequent refresh. The API makes it really easy to consume while they are backed by their own idiosyncrasies. Moving further, it would be a still better option to go for full fledged database storage on the client like IndexedDb which alleviates these issues of Web Storage. It's a more of a balancing act wherein the ease of client side storage is purchased at the cost of performance. But for moderate complexity and volume, my opinion is that Web Storage is a potential candidate.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
13 | |
11 | |
2 | |
1 | |
1 |