Local storage. Using localStorage for JavaScript needs Cookie local storage

This is a pretty standard HTML template that we can fill with dynamically generated content using JavaScript.

JavaScript

Regarding the structure of the simplest notepad application in our example, the first thing we need to do is to ensure that the button click event is tracked. "Add a note" and check if any information is entered into the text field for recording, that is, at the moment of pressing the button, it should not be empty. Something like this:

$ ("# add"). click (function () (
// if the text field is empty
$ ("# alert"). html (" Attention! Enter the entry in the text
field.");
return false;
}

Here's what we do with this piece of code. When the button is pressed "Add a note" we check if the user has entered anything in the field for the new record. If he did not do this, then the div provided by us for displaying messages appears, informing the user that the input field of the record is not filled and then, after 1000ms (1 second), the div element, and accordingly the message, disappears. The function then returns false, after which the browser stops executing the rest of the script and the application is again ready to enter a new record.

Our next step is to add the value entered in the record field to the beginning of the list by generating a new list item. Thus, when the user adds another entry, it will always be placed at the beginning of the list of to-do and expected events. After that, we just have to save the list using the localStorage mechanism:

// Add an entry to the existing list
$ ("# todos"). prepend ("

As you may have noticed, there is nothing unusual here, it is used standard version jQuery code. At the point of accessing the localStorage object, we must specify the data we are saving in the form of a key / value. An arbitrary name can be used for the key, and I named it "todos", then we need to indicate what we, in fact, need to keep in memory. In this case, it is a complete piece of HTML markup, included in an unordered list (located between tags), which displays all the entries previously entered by the user. From the code, you can see that we simply retrieve the fragment we need using the jQuery .html () method and at the end, after completing all the necessary actions, we set the return value of the function to false, which prevents the form data from being submitted and, therefore, our page reloading.

Now, let's say our user has previously made several entries and for the further normal operation of the application, we need to check whether there is information stored on the computer in localStorage and, if so, display it for the user. Since the name of our key is "todos", we must check for its existence as follows:

// if there is already data in the local storage, then display it

}

To check for the presence of data, we used the usual if statement and, when the specified condition was met, we simply fetched all the data from the local storage, placing it as HTML markup inside an unordered list, with the help of which the records entered earlier by the user are displayed.

If you test your simplest application, you will find that after reloading the page, everything stays in place. And now, the last thing that remains for us to do is create a function with which the user can delete all his records if necessary. This is accomplished by clearing localStorage and reloading the page to activate the changes made. Next, we, as in the previous case, set false as the return value of the function, which prevents the hash from appearing in the URL. ( * and does not scroll up the page.):

// Full cleanup localStorage
window.localStorage.clear ();
location.reload ();
return false;
});

As a result, we have a fully functioning application. And putting all the above snippets together, we get the complete application code:

$ ("# add"). click (function () (
var Description = $ ("# description"). val ();
if ($ ("# description"). val () == "") (
$ ("# alert"). html (" Attention! Enter entry in
text field.");
$ ("# alert"). fadeIn (). delay (1000) .fadeOut ();
return false;
}
$ ("# todos"). prepend ("

if (localStorage.getItem ("todos")) (
$ ("# todos"). html (localStorage.getItem ("todos"));
}

$ ("# clear"). click (function () (
window.localStorage.clear ();
location.reload ();
return false;
});

Browser support.

The HTML5 specification provides quite powerful support for Web Storage technology, so that it is also implemented by most popular browsers, even IE8. IE7 remains the only problem if you're still interested.

Conclusion.

In such small applications, the localStorage mechanism can quite successfully replace the use of databases. For storing small amounts of data, it is not necessary to use more sophisticated alternatives.

* Translator's note.

Post Views: 475

Translation: Vlad Merzhevich

Persistent local storage is one area where client applications take advantage of server applications. For applications like operating system, provides an abstraction layer for storing and retrieving data such as settings or execution status. These values ​​can be stored in the registry, INI files, XML files, or elsewhere depending on platform principles. If your client application needs local storage for more than just a key / value pair, you can insert your own database, come up with your own file format, or any number of other solutions.

Historically, web applications have had none of these luxuries. Cookies were invented early in the history of the Internet and can be used to permanently store small amounts of data locally. But they have three potential downsides:

• Cookies are included in every HTTP request, thereby slowing down your web application from unnecessarily transmitting the same data over and over again.
• Cookies are included in every HTTP request when data is transmitted over the Internet in unencrypted form (even if the entire web application is transmitted over SSL);
• Cookies are limited to a data size of about 4 KB - enough to slow down your application (see above), but not enough to be useful.

Here's what we really want:

• a lot of storage space;
• work on the client side;
• take into account page refresh;
• there is no sending to the server.

Before HTML5, all attempts to achieve this ultimately failed in various ways.

A brief history of local storage before HTML5

In the beginning, there was only one Internet Explorer. At least Microsoft wanted the world to think so. To this end, within the framework of the First The great war browsers Microsoft has invented so many things and incorporated them into its browser-which-ended-the-war - Internet Explorer. One of these things was called DHTML Behaviors, and one of the behaviors is called userData.

UserData allows a web page to store up to 64KB of data per domain in a hierarchical XML-like structure. Trusted domains such as intranet sites can store ten times as much. And hey, 640 KB should be enough for everyone. IE has not provided any way to change these conventions, so there is no way to increase the amount of available memory.

In 2002, Adobe introduced a feature in Flash 6, which turned out to be unfortunate and with a misleading name - "Flash Cookies." In the Flash environment, this capability is better known as Local Shared Objects (LSOs). In short, it allows Flash objects to store up to 100KB of data per domain. Brad Neuberg, who developed an early prototype of the bridge between Flash and JavaScript, called it AMASS (AJAX Massive Storage System), but it was limited by some quirks of Flash design. By 2006, with the introduction of ExternalInterface in Flash 8, accessing LSOs via JavaScript has become an order of magnitude easier and faster. Brad rewrote AMASS and integrated it into the popular Dojo Toolkit under the alias dojox.storage. Flash "free" gives each domain 100kb of storage. In addition, it prompts the user to increase the storage capacity by an order of magnitude upon request (1 MB, 10 MB, etc.).

if (Modernizr.localstorage) (
// window.localStorage is available!
) else (
// no native support for HTML5 storage
}

Using HTML5 storage

HTML5 storage is based on the names of key / value pairs. You store information based on the key name, and then you can retrieve that data with the same key. The key name is a string. Data can be any type that JavaScript supports, including strings, booleans, integers, or floating point numbers. However, in reality, the data is stored as a string. If you are saving and retrieving non-strings, you will need to use functions such as parseInt () or parseFloat () to translate the resulting data into valid JavaScript types.

Storage interface (
Get it via getItem (key);
Set via setItem (key, data);
};

Calling setItem () with an existing key name will silently overwrite the previous value. Calling getItem () with a non-existent key will return NULL rather than throwing an exception.

Like other JavaScript objects, you can refer to the localStorage object as an associative array. Instead of using the getItem () and setItem () methods, you can simply specify square brackets... For example this piece of code

var foo = localStorage.getItem ("bar");
// ...
localStorage.setItem ("bar", foo);

can be rewritten using square brackets syntax:

var foo = localStorage ["bar"];
// ...
localStorage ["bar"] = foo;

There are also methods for deleting values ​​by key name, as well as clearing the entire store (that is, deleting all keys and values ​​at the same time).

Storage interface (
Remove via removeItem (key);
clear ();
}

Calling removeItem () with a non-existent key will return nothing.

Finally, there is a property for getting the total number of values ​​in the storage area and for iterating over all keys by index (gets the name of each key).

Storage interface (
length
Get key (non-negative integer);
}

If, when calling key (), the index is not in the range from 0 to (length-1), then the function will return null.

Tracking the HTML5 storage area

If you want to programmatically track storage changes, you must catch the storage event. This event fires on the window object when setItem (), removeItem (), or clear () is called and changes something. For example, if you set an existing value or call clear () when there are no keys, then the event will not fire because the storage area has not really changed.

The storage event is supported wherever the localStorage object works, including Internet Explorer 8. IE 8 does not support the W3C addEventListener standard (although it will finally be added in IE 9), so to catch the storage event you need to check which event engine supports browser (if you've done this before with other events, you can skip this section to the end). Intercepting the storage event works in the same way as intercepting other events. If you prefer to use jQuery or some other JavaScript library to register event handlers, you can do this with storage too.

if (window.addEventListener) (
window.addEventListener ("storage", handle_storage, false);
) else (
window.attachEvent ("onstorage", handle_storage);
};

The handle_storage callback will be called with the StorageEvent object, except in Internet Explorer, where events are stored in window.event.

function handle_storage (e) (
if (! e) (e = window.event;)
}

In this case, e will be a StorageEvent object that has the following useful properties.

* Note: the url property was originally called uri and some browsers supported this property prior to the specification change. For maximum compatibility, you should check if the url property exists, and if not, check the uri property instead.

The storage event cannot be canceled, there is no way to stop the change inside the handle_storage callback. It's just the browser's way of telling you, “Hey, this just happened. There is nothing you can do, I just wanted you to know. "

Limitations in current browsers

When talking about the history of local storage with third party plugins, I mentioned the limitations of each technique. I remembered that I hadn't said anything about the limitations of the now standard HTML5 storage. I will give you the answers and then I will explain them. The answers, in order of importance, are “5 megabytes”, “QUOTA_EXCEEDED_ERR”, and “no”.

"5 megabytes" - how much storage space is provided by default. This meaning is surprisingly the same across all browsers, although it is phrased as nothing more than a proposal in the HTML5 spec. You need to understand that you are storing strings, not data in its original format. If you store a lot of integers or floating point numbers, the difference in representation can be large. Each digit in a floating point number is stored as a character and not in the usual representation for such numbers.

"QUOTA_EXCEEDED_ERR" is the exception you get if you exceed your 5MB quota. "No" is the answer to the next obvious question: "Can I ask the user for more storage space?" At the time of writing, browsers have not implemented any mechanism for web developers to request more storage space. Some browsers (like Opera) allow the user to control storage quotas for each site, but this is purely a user initiative and not something that you, as a developer, can embed in your web application.

HTML5 storage in action

Let's take a look at HTML5 storage in action. Let's go back to the one we built in the drawing chapter. There is a small problem with this game: if you close the browser window in the middle of the game, you will lose results. But with HTML5 storage, we can keep the gameplay in place, in the browser itself. Open the demo, take a few moves, close the browser tab, and then reopen it. If your browser supports HTML5 storage, the demo page will magically remember the exact position in the game, including how many moves you made, the position of each piece on the board, and even the selected piece.

How it works? Every time there is a change in the game, we will call this function.

function saveGameState () (

localStorage ["halma.game.in.progress"] = gGameInProgress;
for (var i = 0; i< kNumPieces; i++) {
localStorage ["halma.piece." + i + ".row"] = gPieces [i] .row;
localStorage ["halma.piece." + i + ".column"] = gPieces [i] .column;
}
localStorage ["halma.selectedpiece"] = gSelectedPieceIndex;
localStorage ["halma.selectedpiecehasmoved"] = gSelectedPieceHasMoved;
localStorage ["halma.movecount"] = gMoveCount;
return true;
}

As you can see, the localStorage object is used to save the game process (gGameInProgress, boolean). Next, all the tokens (gPieces, JavaScript array) are iterated over and a row and column are stored for each of them. After that, some additional game states are saved, including the selected piece (gSelectedPieceIndex, integer), the piece that is in the middle of a long series of jumps (gSelectedPieceHasMoved, boolean) and the total number of moves made (gMoveCount, integer).

When the page loads, instead of automatically calling the newGame () function, which would return all variables to their original values, we call resumeGame (). The resumeGame () function uses HTML5 storage to check the state of the game in the local storage. If present, it restores the values ​​using the localStorage object.

function resumeGame () (
if (! supportsLocalStorage ()) (return false;)
gGameInProgress = (localStorage ["halma.game.in.progress"] == "true");
if (! gGameInProgress) (return false;)
gPieces = new Array (kNumPieces);
for (var i = 0; i< kNumPieces; i++) {
var row = parseInt (localStorage ["halma.piece." + i + ".row"]);
var column = parseInt (localStorage ["halma.piece." + i + ".column"]);
gPieces [i] = new Cell (row, column);
}
gNumPieces = kNumPieces;
gSelectedPieceIndex = parseInt (localStorage ["halma.selectedpiece"]);
gSelectedPieceHasMoved = localStorage ["halma.selectedpiecehasmoved"] == "true";
gMoveCount = parseInt (localStorage ["halma.movecount"]);
drawBoard ();
return true;
}

The most important part of this function is the caveat that I mentioned earlier in this chapter and will repeat here: data is stored as strings. If you are storing something other than strings, you need to convert them on receipt. For example, the flag that the game is in progress (gGameInProgress) is a boolean type. In the saveGameState () function, we just store it and don't worry about the data type.

localStorage ["halma.game.in.progress"] = gGameInProgress;

But in resumeGame (), we have to look at the value we got from local storage as a string and manually construct our own boolean.

gGameInProgress = (localStorage ["halma.game.in.progress"] == "true");

Likewise, the number of moves is stored in gMoveCount as an integer, in the saveGameState () function we simply save it.

localStorage ["halma.movecount"] = gMoveCount;

But in resumeGame (), we have to convert the value to an integer using JavaScript's built-in parseInt () function.

gMoveCount = parseInt (localStorage ["halma.movecount"]);

Beyond Key / Value Pair: Competitive Vision

While there have been many tricks and workarounds in history, the current state of HTML5 storage is surprisingly good. The new API has been standardized and included in all major browsers, platforms and devices. For a web developer you don't see this every day, right? But that's more than "5 megabytes of key / value pairs" and the future of persistent local storage is ... how to say ... well, let it be a competitive vision.

One vision is an acronym you already know - SQL. In 2007, Google launched Gears, a cross-browser plugin with open source source code which includes an embedded SQLite based database. This early prototype later influenced the creation of the Web SQL Database specification. Web SQL Database (formerly known as "WebDB") provides a thin wrapper around the database SQL data, which allows you to do the following things from JavaScript:

openDatabase ("documents", "1.0", "Local document storage", 5 * 1024 * 1024, function (db) (
db.changeVersion ("", "1.0", function (t) (
t.executeSql ("CREATE TABLE docids (id, name)");
), error);
});

As you can see, most of the action is on the line with the ExecuteSQL method. This string can support any SQL command, including SELECT, UPDATE, INSERT, and DELETE. It's like server-side database programming, except that you do it with JavaScript! Oh joy!

The Web SQL Database specification has been implemented across four browsers and platforms.

Of course, if you've used more than one database in your life, then you know that "SQL" is more of a marketing term than a hard and fast standard (someone might say the same about HTML5, but that doesn't matter). Of course, there is an up-to-date SQL specification (called SQL-92), but there is no database server in the world that only conforms to this specification. There is Oracle SQL, Microsoft SQL, SQL in MySQL, SQL in PostgreSQL, SQL in SQLite. In fact, each of these products adds new ones over time. SQL functions, so even saying "SQL in SQLite" is not enough. You must say "the version of SQL that comes with the SQLite version X.Y.Z".

All of this brings us to the next caveat, currently at the top of the Web SQL specification.

The spec is at an impasse: all interested developers are using server-side SQL (SQLite), but we need multiple independent implementations to move towards standardization. While other developers are interested in implementing this specification, the SQL dialect description has been left as a regular reference to Sqlite, which is not acceptable to the standard.

It is against this backdrop that I will share with you another competitive vision for advanced, persistent local storage for web applications: the Indexed Database API, formerly known as “WebSimpleDB,” now affectionately called IndexedDB.

The Indexed Database API provides what is called object storage, with a lot of ideas borrowed from SQL databases. There are “databases” with “records”, each record has a certain number of “fields”. Each field has a specific data type that is defined when the database is created. You can select part of the records, then list them with the "cursor". Changes to object storage are processed with "transactions".

If you've ever programmed SQL databases, these terms are probably familiar to you. The main difference is that object storage does not have a structured query language. You don't write a condition like "SELECT * from USERS where ACTIVE =" Y "". Instead, it uses the methods provided by the object store to open the USERS database, enumerate the records, filter our records, and use accessor methods to get the value of each field of the remaining records. An early walk-through of IndexedDB is a good guide on how IndexedDB works and comparing IndexedDB to Web SQL.

At the time of writing, IndexedDB has only been implemented in the beta version of Firefox 4. In contrast, Mozilla has stated that it will never implement Web SQL. Google said they are considering IndexedDB support for Chromium and Google chrome... And even Microsoft says IndexedDB is "great for the web."

What can you do as a web developer with IndexedDB? On this moment practically nothing other than some technology demonstrations. In a year? Perhaps.