Stockage de données local. Travailler avec le stockage local en JavaScript. Que devrais-tu faire ensuite?

Le API de stockage Web fournit des mécanismes par lesquels les navigateurs peuvent stocker des paires clé/valeur, d'une manière beaucoup plus intuitive que l'utilisation de cookies.

Concepts et utilisation du stockage Web

Les deux mécanismes de Web Storage sont les suivants :

• sessionStorage maintient une zone de stockage distincte pour chaque origine donnée, disponible pendant toute la durée de la session de page (tant que le navigateur est ouvert, y compris les rechargements et les restaurations de page)
  • Stocke les données uniquement pour une session, ce qui signifie que les données sont stockées jusqu'à la fermeture du navigateur (ou de l'onglet).
  • Les données ne sont jamais transférées au serveur.
  • La limite de stockage est supérieure à celle d'un cookie (au maximum 5 Mo).
• localStorage fait la même chose, mais persiste même lorsque le navigateur est fermé et rouvert.
  • Stocke les données sans date d'expiration et est effacée uniquement via JavaScript ou en effaçant le cache du navigateur / les données stockées localement.
  • La limite de stockage est le maximum parmi les trois.

Caractéristiques

Compatibilité du navigateur

Window.localStorage

https://github.com/mdn/browser-compat-data et envoyez-nous une pull request.

Légende

Window.sessionStorage

Le tableau de compatibilité sur cette page est généré à partir de données structurées. Si vous souhaitez contribuer aux données, veuillez consulter https://github.com/mdn/browser-compat-data et envoyez-nous une pull request.

Mettre à jour les données de compatibilité sur GitHub

Légende

Modes navigation privée / navigation privée

La plupart des navigateurs modernes prennent en charge une option de confidentialité appelée "Incognito", "Navigation privée" ou quelque chose de similaire qui ne stocke pas de données comme l'historique et les cookies. Ceci est fondamentalement incompatible avec le stockage Web pour des raisons évidentes. En tant que tel, les fournisseurs de navigateurs expérimentent différentes scénarios sur la façon de gérer cette incompatibilité.

La plupart des navigateurs ont opté pour une stratégie dans laquelle les API de stockage sont toujours disponibles et apparemment entièrement fonctionnelles, avec la seule grande différence que toutes les données stockées sont effacées après la fermeture du navigateur. Pour ces navigateurs, il existe encore différentes interprétations de ce qui doit être fait avec les données stockées existantes (à partir d'une session de navigation normale). Doit-il être disponible en lecture en mode privé ? Ensuite, certains navigateurs, notamment Safari, ont opté pour une solution dans laquelle le stockage est disponible, mais vide et doté d'un quota de 0 octet, ce qui rend effectivement impossible l'écriture de données.

Les développeurs doivent être conscients de ces différentes implémentations et en tenir compte lors du développement de sites Web dépendant des API Web Storage. Pour plus d'informations, veuillez consulter cet article du blog WHATWG qui traite spécifiquement de ce sujet.

Je vous ai envoyé un article avec une histoire sur HTML5 LocalStorage dans les navigateurs. Nous lui donnons la parole.

J'ai essayé d'écrire le guide le plus simple et le plus compréhensible sur l'utilisation de la technologie localStorage. L'article s'est avéré assez court, car la technologie elle-même et les moyens de l'utiliser ne sont pas compliqués. Pour commencer, il vous suffit de connaître un peu JavaScript. Alors, consacrez 10 minutes à cet article et vous pourrez ajouter en toute sécurité la ligne « Je peux travailler avec localStorage » à votre CV.

Qu’est-ce que le stockage local ?

Voici à quoi ressemble un objet JavaScript :

Var myCar = ( roues : 4, portes : 4, moteur : 1, nom : "Jaguar")

Et voici à quoi ressemble JSON. Presque comme un objet js classique, seules toutes les propriétés doivent être placées entre guillemets.

( "firstName": "Ivan", "lastName": "Ivanov", "address": ( "streetAddress": "Moskovskoe sh., 101, apt. 101", "city": "Leningrad", "postalCode": 101101 ), "numéros de téléphone": [ "812 123-1234", "916 123-4567" ] )

Pour comprendre ce qu'est localStorage, imaginez simplement que vous ayez un tel objet intégré quelque part dans votre navigateur que nous pouvons utiliser. En même temps, cet objet n'efface pas les valeurs que l'on y écrit si l'on recharge la page ou même si l'on ferme complètement le navigateur.

En termes JavaScript, localStorage est une propriété de l'objet navigateur global (fenêtre). Il est accessible sous le nom window.localStorage ou simplement localStorage.

Il convient également de dire que le navigateur dispose d'un clone de localStorage appelé sessionStorage. Leur seule différence est que ce dernier stocke les données d'un seul onglet (session) et videra simplement son espace dès que l'on fermera l'onglet

Regardons ça en direct. Par exemple, dans Google Chrome vous devez ouvrir DevTools (F12), aller dans l'onglet « Ressources » et dans le panneau de gauche vous verrez localStorage pour ce domaine et toutes les valeurs qu'il contient.

À propos, vous devez savoir comment localStorage fonctionne avec les domaines. Pour chaque domaine, votre navigateur crée son propre objet localStorage, et il ne peut être modifié ou affiché que sur ce domaine. Par exemple, le domaine mydomain-1.com ne peut pas accéder au localStorage de votre mydomain-2.com .

Pourquoi ai-je besoin de localStorage ?

LocalStorage n'est nécessaire que pour une seule chose : stocker certaines données entre les sessions utilisateur. Vous pouvez penser à mille et une choses qui peuvent être stockées dans le stockage local du navigateur. Par exemple, les jeux par navigateur qui l'utilisent comme fichier de sauvegarde, ou enregistrent le moment où l'utilisateur s'est arrêté en regardant une vidéo, diverses données pour les formulaires, etc.

Comment démarrer avec localStorage ?

Très simple.

Travailler avec localStorage est très similaire à travailler avec des objets en JavaScript. Il existe plusieurs méthodes pour travailler avec.

localStorage.setItem("clé", "valeur")

Méthode qui s'ajoute à localStorage nouvelle clé avec une valeur (et si une telle clé existe déjà, elle l'écrase avec une nouvelle valeur). On écrit par exemple localStorage.setItem('myKey', 'myValue');

localStorage.getItem("clé")

Nous prenons une valeur spécifique du stockage des clés.

localStorage.removeItem("Clé")

Retirer la clé

localStorage.clear()

Effacer tout le stockage

Vous pouvez maintenant ouvrir l'onglet localStorage dans votre navigateur et vous entraîner vous-même à enregistrer et à récupérer les données de ce stockage. Si quelque chose arrive, nous écrivons tout le code dans un fichier js.

//Ajoutez ou modifiez la valeur : localStorage.setItem("myKey", "myValue"); //vous avez maintenant la clé "myKey" avec la valeur "myValue" stockée dans localStorage //Envoyez-la sur la console : var localValue = localStorage.getItem("myKey"); console.log(localValue); //"maValue" //supprimer : localStorage.removeItem("maClé"); //efface tout le stockage localStorage.clear() La même chose, uniquement avec des crochets : localStorage["Key"] = "Value" //définition de la valeur localStorage["Key"] //Obtention de la valeur delete localStorage[" Clé"] // Supprimer la valeur

Je voudrais également noter que localStorage fonctionne très bien avec les structures imbriquées, par exemple les objets.

//crée un objet var obj = ( item1: 1, item2: , item3:"hello" ); var sérieObj = JSON.stringify(obj); //sérialise-le localStorage.setItem("myKey", serialObj); // l'écrit dans le stockage à l'aide de la clé "myKey" var returnObj = JSON.parse(localStorage.getItem("myKey")) // l'analyse en tant qu'objet

Il faut également savoir que les navigateurs allouent 5 Mo pour le stockage local. Et si vous le dépassez, vous recevrez une exception QUOTA_EXCEEDED_ERR. À propos, vous pouvez l'utiliser pour vérifier s'il reste encore de l'espace dans votre stockage.

Essayez ( localStorage.setItem("key", "value"); ) catch (e) ( if (e == QUOTA_EXCEEDED_ERR) ( alert("Limite dépassée"); ) )

Au lieu d'une conclusion

J'aimerais que les développeurs tirent une conclusion simple de ce court article : cette technologie peut déjà être utilisé pleinement sur vos projets. Il bénéficie d'une bonne standardisation et d'un excellent support, qui ne se développe qu'avec le temps.

Traduction : Vlad Merjevitch

Le stockage local persistant est un domaine dans lequel les applications client présentent des avantages par rapport aux applications serveur. Pour des applications telles que système opérateur, fournit une couche d'abstraction pour stocker et récupérer des données telles que les paramètres ou l'état d'exécution. Ces valeurs peuvent être stockées dans le registre, dans des fichiers INI, des fichiers XML ou ailleurs selon les principes de la plateforme. Si votre application client a besoin d'un stockage local pour plus qu'une simple paire clé/valeur, vous pouvez insérer votre propre base de données, créer votre propre format de fichier ou tout autre solution.

Historiquement, les applications Web n’ont eu aucun de ces luxes. Les cookies ont été inventés au début de l’histoire d’Internet et peuvent être utilisés pour stocker de manière permanente de petites quantités de données localement. Mais ils présentent trois inconvénients potentiels :

• Les cookies sont inclus dans chaque requête HTTP, ralentissant ainsi votre application Web en transmettant inutilement les mêmes données encore et encore ;
• les cookies sont inclus dans chaque requête HTTP lors de la transmission de données sur Internet sous forme non cryptée (même si l'intégralité de l'application Web est transmise via SSL) ;
• Les cookies sont limités à environ 4 Ko de données – suffisamment pour ralentir votre application (voir ci-dessus), mais pas suffisamment pour être utiles.

Voici ce que nous voulons vraiment :

• beaucoup d'espace de rangement ;
• travailler côté client ;
• prendre en compte les rafraîchissements de pages ;
• pas d'envoi au serveur.

Avant HTML5, toutes les tentatives pour y parvenir ont finalement échoué de diverses manières.

Une brève histoire du stockage local avant HTML5

Au début, il n’existait qu’un seul Internet Explorer. C'est du moins ce que Microsoft voulait faire croire au monde. A cet effet, dans le cadre du Premier Grande Guerre navigateurs Microsoft a inventé beaucoup de choses et les a incluses dans son navigateur qui a mis fin à la guerre, Internet Explorer. L'une de ces choses s'appelait DHTML Behaviors, et l'un des comportements s'appelait userData.

UserData permet à une page Web de stocker jusqu'à 64 Ko de données par domaine dans une structure hiérarchique de type XML. Les domaines de confiance tels que les sites intranet peuvent en stocker dix fois plus. Et bon, 640 Ko devraient suffire à tout le monde. IE n'a fourni aucun moyen de modifier ces conventions, il n'y a donc aucun moyen d'augmenter la quantité de mémoire disponible.

En 2002, Adobe a introduit une fonctionnalité dans Flash 6 qui n’a pas abouti et qui s’appelait à tort « Flash Cookies ». DANS Environnement Flash cette fonctionnalité est plus connue sous le nom d'objets partagés locaux (LSO). En bref, il permet aux objets Flash de stocker jusqu'à 100 Ko de données par domaine. Brad Neuberg, qui a développé un premier prototype de pont entre Flash et JavaScript, l'a appelé AMASS (AJAX Massive Storage System), mais il était limité par certaines bizarreries de la conception Flash. En 2006, avec l'introduction d'ExternalInterface dans Flash 8, l'accès aux LSO via JavaScript est devenu beaucoup plus facile et plus rapide. Brad a réécrit AMASS et l'a intégré dans la populaire boîte à outils Dojo sous l'alias dojox.storage. Flash donne à chaque domaine 100 Ko de stockage « gratuitement ». De plus, il propose à l'utilisateur, sur demande, d'augmenter le volume de stockage d'un ordre de grandeur (1 Mo, 10 Mo, etc.).

si (Modernizr.localstorage) (
// window.localStorage est disponible !
) autre (
// pas de support natif pour le stockage HTML5
}

Utiliser le stockage HTML5

Le stockage HTML5 est basé sur les noms de paires clé/valeur. Vous stockez des informations en fonction du nom de la clé, puis vous pouvez récupérer ces données avec la même clé. Le nom de la clé est une chaîne. Les données peuvent être de n'importe quel type pris en charge par JavaScript, notamment des chaînes, des booléens, des entiers ou des nombres à virgule flottante. Cependant, en réalité, les données sont stockées sous forme de chaîne. Si vous stockez et récupérez des non-chaînes, vous devrez utiliser des fonctions telles que parseInt() ou parseFloat() pour convertir les données reçues dans les types JavaScript corrects.

Interface de stockage (
Obtenez via getItem(key);
Définir via setItem (clé, données);
};

L’appel de setItem() avec un nom de clé existant écrasera silencieusement la valeur précédente. L'appel de getItem() avec une clé inexistante renverra NULL plutôt que de lever une exception.

Comme les autres objets JavaScript, vous pouvez accéder à l'objet localStorage en tant que tableau associatif. Au lieu d'utiliser les méthodes getItem() et setItem(), vous pouvez simplement spécifier des crochets. Par exemple cet extrait de code

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

peut être réécrit en utilisant la syntaxe entre crochets :

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

Il existe également des méthodes pour supprimer des valeurs par nom de clé, ainsi que pour effacer l'intégralité du magasin (c'est-à-dire supprimer toutes les clés et valeurs à la fois).

Interface de stockage (
Supprimer via removeItem(key);
clair();
}

Appeler RemoveItem() avec une clé inexistante ne renverra rien.

Enfin, il existe une propriété pour obtenir le nombre total de valeurs dans la zone de stockage et pour parcourir toutes les clés par index (obtient le nom de chaque clé).

Interface de stockage (
longueur
Obtenir la clé (entier non négatif) ;
}

Si, lorsque key() est appelé, l'index n'est pas compris entre 0 et (longueur-1), alors la fonction renverra null .

Surveillance de la zone de stockage HTML5

Si vous souhaitez suivre par programmation les modifications du stockage, vous devez intercepter l'événement de stockage. Cet événement se produit sur l'objet window lorsque setItem() , removeItem() ou clear() sont appelés et modifient quelque chose. Par exemple, si vous avez installé valeur existante ou appelé clear() lorsqu'il n'y a pas de clés, l'événement ne se déclenchera pas car la zone de stockage n'a pas réellement changé.

L'événement de stockage est pris en charge partout où l'objet localStorage s'exécute, y compris Internet Explorer 8. IE 8 ne prend pas en charge la norme W3C addEventListener (bien qu'il soit finalement ajouté dans IE 9), donc pour capturer l'événement de stockage, vous devez vérifier quel moteur d'événements le prend en charge par le navigateur (si vous l'avez déjà fait avec d'autres événements, vous pouvez passer à la fin de cette section). L'interception de l'événement de stockage fonctionne de la même manière que l'interception d'autres événements. Si vous préférez utiliser jQuery ou une autre bibliothèque JavaScript pour enregistrer les gestionnaires d'événements, vous pouvez également le faire avec le stockage.

si (window.addEventListener) (
window.addEventListener("stockage", handle_storage, false);
) autre (
window.attachEvent("onstorage", handle_storage);
};

Le rappel handle_storage sera appelé avec l'objet StorageEvent, sauf dans Internet Explorer, où les événements sont stockés dans window.event .

fonction handle_storage(e) (
si (!e) ( e = window.event; )
}

Dans ce cas, la variable e sera un objet StorageEvent, qui possède les propriétés utiles suivantes.

*Remarque : la propriété url s'appelait à l'origine uri et certains navigateurs prenaient en charge cette propriété avant que la spécification ne change. Pour garantir une compatibilité maximale, vous devez vérifier si la propriété url existe, et sinon, vérifier plutôt la propriété uri.

L'événement de stockage ne peut pas être annulé et il n'existe aucun moyen d'arrêter la modification dans le rappel handle_storage. C'est simplement une façon pour le navigateur de vous dire : « Hé, cela vient d'arriver. Vous ne pouvez rien faire, je voulais juste que vous le sachiez. »

Limitations des navigateurs actuels

En parlant de l’histoire du stockage local utilisant des plugins tiers, j’ai évoqué les limites de chaque technique. Je me suis rappelé que je n'avais rien dit sur les limitations du stockage HTML5 désormais standard. Je vais vous donner les réponses et ensuite les expliquer. Les réponses, par ordre d'importance, sont « 5 mégaoctets », « QUOTA_EXCEEDED_ERR » et « aucun ».

"5 mégaoctets" - combien d'espace de stockage est fourni par défaut. Cette valeur est étonnamment cohérente dans tous les navigateurs, même si elle n'est indiquée que comme une simple suggestion dans la spécification HTML5. Vous devez comprendre que vous stockez des chaînes et non des données au format d'origine. Si vous stockez beaucoup d’entiers ou de nombres à virgule flottante, la différence de représentation peut être importante. Chaque chiffre d'un nombre à virgule flottante est stocké sous forme de caractère, plutôt que dans la représentation habituelle de ces nombres.

"QUOTA_EXCEEDED_ERR" est l'exception que vous recevrez si vous dépassez votre quota de 5 Mo. « Non » est la réponse à la prochaine question évidente : « Puis-je demander à l'utilisateur plus d'espace de stockage ? » Au moment de la rédaction de cet article, les navigateurs n'implémentent aucun mécanisme permettant aux développeurs Web de demander plus d'espace de stockage. Certains navigateurs (tels qu'Opera) permettent à l'utilisateur de contrôler les quotas de stockage par site, mais il s'agit uniquement d'une initiative de l'utilisateur et sans rapport avec tout ce que vous, en tant que développeur, pouvez intégrer dans votre application Web.

Le stockage HTML5 en action

Jetons un coup d'œil au stockage HTML5 en action. Revenons à celui que nous avons construit dans le chapitre sur le dessin. Il y a un petit problème avec ce jeu : si vous fermez la fenêtre du navigateur en plein jeu, vous perdrez les résultats. Mais avec le stockage HTML5, nous pouvons sauvegarder le processus de jeu localement, dans le navigateur lui-même. Ouvrez la démo, effectuez quelques mouvements, fermez l'onglet du navigateur, puis rouvrez-le. Si votre navigateur prend en charge le stockage HTML5, la page de démonstration se souviendra comme par magie de la position exacte dans le jeu, y compris le nombre de mouvements que vous avez effectués, la position de chaque pièce sur le plateau et même la pièce sélectionnée.

Comment ça fonctionne? Chaque fois qu'il y aura un changement dans le jeu, nous appellerons cette fonction.

fonction saveGameState() (

localStorage["halma.game.in.progress"] = gGameInProgress;
pour (var je = 0; je< kNumPieces; i++) {
localStorage["halma.pièce." + je + ".row"] = gPièces[i].row;
localStorage["halma.pièce." + je + ".column"] = gPièces[i].column;
}
localStorage["halma.selectedpiece"] = gSelectedPièceIndex;
localStorage["halma.selectedpiecehasmoved"] = gSelectedPièceHasMoved;
localStorage["halma.movecount"] = gMoveCount;
renvoie vrai ;
}

Comme vous pouvez le constater, l'objet localStorage permet de sauvegarder la progression du jeu (gGameInProgress, type booléen). Ensuite, tous les éléments (gPièces, un tableau JavaScript) sont itérés et une ligne et une colonne sont enregistrées pour chacun d'eux. Certains états de jeu supplémentaires sont ensuite enregistrés, notamment la pièce sélectionnée (gSelectedPièceIndex, entier), la pièce qui se trouve au milieu d'une longue série de sauts (gSelectedPièceHasMoved, booléen), et nombre total mouvements effectués (gMoveCount, entier).

Lorsque la page se charge, au lieu d'appeler automatiquement la fonction newGame(), qui ramènerait toutes les variables à leurs valeurs d'origine, nous appelons curriculum vitae() . La fonction curriculum vitae() utilise le stockage HTML5 pour vérifier l'état du jeu dans le stockage local. S'il est présent, il restaure les valeurs à l'aide de l'objet localStorage.

fonction reprendreGame() (
if (!supportsLocalStorage()) ( return false; )
gGameInProgress = (localStorage["halma.game.in.progress"] == "true");
if (!gGameInProgress) ( return false; )
gPièces = nouveau tableau (kNumPièces);
pour (var je = 0; je< kNumPieces; i++) {
var row = parseInt(localStorage["halma.piece." + i + ".row"]);
var colonne = parseInt(localStorage["halma.piece." + i + ".column"]);
gPièces[i] = new Cell (ligne, colonne);
}
gNumPièces = kNumPièces ;
gSelectedPièceIndex = parseInt(localStorage["halma.selectedpiece"]);
gSelectedPièceHasMoved = localStorage["halma.selectedpiecehasmoved"] == "true";
gMoveCount = parseInt(localStorage["halma.movecount"]);
drawBoard();
renvoie vrai ;
}

La partie la plus importante de cette fonctionnalité est une mise en garde que j'ai mentionnée plus tôt dans ce chapitre et que je répéterai ici : les données sont stockées sous forme de chaînes. Si vous stockez autre chose que des chaînes, vous devrez les convertir lorsque vous les recevrez. Par exemple, l'indicateur indiquant qu'un jeu est en cours (gGameInProgress) est de type booléen. Dans la fonction saveGameState(), nous le stockons simplement et ne nous soucions pas du type de données.

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

Mais dans la fonction curriculum vitae(), nous devons examiner la valeur récupérée du stockage local sous forme de chaîne et construire manuellement notre propre valeur booléenne.

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

De même, le nombre de coups est stocké dans gMoveCount sous forme d'entier, dans la fonction saveGameState() nous le sauvegardons simplement.

localStorage["halma.movecount"] = gMoveCount;

Mais dans la fonction reprendreGame(), nous devons convertir la valeur en entier à l'aide de la fonction parseInt() intégrée de JavaScript.

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

Au-delà des paires clé/valeur : vision concurrentielle

Bien qu'il y ait eu de nombreuses astuces et solutions de contournement au cours de l'histoire, l'état actuel du stockage HTML5 est étonnamment sain. La nouvelle API a été standardisée et incluse dans tous les principaux navigateurs, plates-formes et appareils. Pour un développeur Web, ce n’est pas quelque chose que l’on voit tous les jours, n’est-ce pas ? Mais cela ne se résume pas à « 5 mégaoctets de paires clé/valeur » et l’avenir du stockage local persistant est… comment devrais-je dire… eh bien, disons que c’est une vision compétitive.

Une vision est un acronyme que vous connaissez déjà : SQL. En 2007, Google a lancé Gears, un plugin multi-navigateur open source qui comprend une base de données SQLite intégrée. Ce premier prototype a influencé plus tard la création de la spécification Web SQL Database. Web SQL Database (anciennement connu sous le nom de « WebDB ») fournit un mince wrapper autour de la base de données Données SQL, qui vous permet d'effectuer les opérations suivantes à partir de JavaScript :

openDatabase("documents", "1.0", "Stockage local de documents", 5*1024*1024, fonction (db) (
db.changeVersion("", "1.0", fonction (t) (
t.executeSql("CREATE TABLE docids (id, nom)");
), erreur);
});

Comme vous pouvez le voir, la plupart des actions sont conformes à la méthode ExecuteSQL. Cette chaîne peut prendre en charge n'importe quelle commande SQL, notamment SELECT, UPDATE, INSERT et DELETE. C'est juste comme ça programmation serveur bases de données, sauf que vous le faites avec JavaScript ! Ô joie !

La spécification de base de données Web SQL a été implémentée dans quatre navigateurs et plates-formes.

Bien sûr, si vous avez utilisé plus d'une base de données dans votre vie, vous savez que « SQL » est plus un terme marketing qu'un standard strict (certains pourraient dire la même chose à propos de HTML5, mais cela n'a pas d'importance). . Bien sûr, il existe actuellement une spécification SQL (appelée SQL-92), mais il n'existe aucun serveur de base de données au monde qui se conforme uniquement à cette spécification. Il existe Oracle SQL, Microsoft SQL, SQL dans MySQL, SQL dans PostgreSQL, SQL dans SQLite. En fait, chacun de ces produits ajoute de nouvelles fonctionnalités SQL au fil du temps, donc même dire « SQL dans SQLite » ne suffit pas. Vous devriez dire "version de SQL fournie avec la version SQLite X.Y.Z".

Tout cela nous amène à la clause de non-responsabilité suivante, actuellement affichée en haut de la spécification Web SQL.

La spécification est dans une impasse : tous les développeurs intéressés utilisent SQL côté serveur (SQLite), mais nous avons besoin de plusieurs implémentations indépendantes pour progresser vers la standardisation. Alors que d'autres développeurs souhaitent implémenter cette spécification, la description du dialecte SQL a été laissée comme une simple référence à SQLite, ce qui n'est pas acceptable pour la norme.

C'est dans ce contexte que je vais vous parler d'une autre vision concurrentielle du stockage local avancé et persistant pour les applications Web : l'API Indexed Database, anciennement connue sous le nom de « WebSimpleDB », désormais affectueusement appelée IndexedDB.

L'API Indexed Database fournit ce qu'on appelle le stockage d'objets, avec de nombreuses idées empruntées aux bases de données SQL. Il existe des « bases de données » avec des « enregistrements », chaque enregistrement comportant un certain nombre de « champs ». Chaque champ possède un type de données spécifique, déterminé lors de la création de la base de données. Vous pouvez sélectionner un sous-ensemble d'enregistrements, puis les lister avec le « curseur ». Les modifications apportées au magasin d'objets sont traitées avec des "transactions".

Si vous avez déjà programmé des bases de données SQL, ces termes vous sont probablement familiers. La principale différence est que le stockage objet ne dispose pas de langage de requête structuré. Vous n'écrivez pas de condition comme "SELECT * from UTILISATEURS où ACTIVE = "Y"". Au lieu de cela, nous utilisons les méthodes fournies par le magasin d'objets pour ouvrir la base de données USERS, énumérer les enregistrements, filtrer nos enregistrements et utiliser des méthodes d'accès pour obtenir la valeur de chaque champ des enregistrements restants. Une première présentation d'IndexedDB est un bon didacticiel sur le fonctionnement d'IndexedDB et la manière dont IndexedDB se compare à Web SQL.

Au moment de la rédaction de cet article, IndexedDB n'a été implémenté que dans la version bêta de Firefox 4. En revanche, Mozilla a déclaré qu'il n'implémenterait jamais Web SQL. Google a déclaré qu'il envisageait la prise en charge d'IndexedDB pour Chromium et Google Chrome. Et même Microsoft a déclaré qu'IndexedDB était « une excellente solution pour le Web ».

Que pouvez-vous faire en tant que développeur Web avec IndexedDB ? Pour le moment, presque rien à part quelques démonstrations technologiques. Dans un an? Peut être.

Traduction de l'article : Comment utiliser le stockage local pour JavaScript.
Sara Vieira.

Apprendre les bases de la programmation JavaScript commence souvent par la création d'applications simples, comme le carnet électronique que nous utilisons pour enregistrer des choses et des événements que nous pourrions oublier. Mais ces applications se caractérisent par un problème : une fois la page rechargée, la liste de toutes les entrées précédemment laissées disparaît, c'est-à-dire que l'application revient à son état d'origine.

Il existe un moyen très simple de sortir de cette situation, qui consiste à utiliser le mécanisme de stockage local localStorage. Grâce au fait que localStorage nous permet de sauvegarder les données nécessaires sur l'ordinateur de l'utilisateur, la liste des tâches et événements planifiés mentionnés ci-dessus sera toujours disponible après un rechargement de la page, de plus, localStorage est étonnamment très d'une manière simple stocker des données et y accéder si nécessaire.

Qu’est-ce que le stockage local ?

Il s'agit d'un mécanisme de stockage de données local qui fait partie de la technologie Web Storage fournie par la spécification HTML5. Il existe deux options de stockage de données autorisées par cette spécification :

• Stockage local: vous permet de sauvegarder des informations sans restrictions sur les périodes de stockage. C'est cette option que nous utiliserons, puisque la liste des tâches de notre exemple doit être stockée de manière permanente.
• Utiliser des séances : assure la sécurité des données uniquement pendant la durée d'une session, c'est-à-dire qu'après que l'utilisateur ferme l'onglet de notre application et l'ouvre à nouveau, toutes les informations nécessaires au fonctionnement ultérieur de l'application seront supprimées.

En termes simples, Web Storage ne fait que stocker les données sous la forme clé/valeur nommée localement et contrairement aux deux autres méthodes qui présentent chacune leurs propres inconvénients ( Stockage des informations de session implique pour cela l'utilisation du côté serveur, de plus, après la fermeture de la session utilisateur, ces informations sont supprimées et les cookies, bien qu'ils utilisent le côté client pour le stockage, ne sont pas fiables car l'utilisateur peut annuler leur prise en charge via les paramètres du navigateur.) enregistre les données même dans ce cas, si vous avez fermé votre navigateur ou éteint votre ordinateur. ( *J'ai pris la liberté de modifier légèrement et d'ajouter du contenu à ce paragraphe, car je pense que l'auteur a commis des inexactitudes dans l'original.)

HTML

Si nous nous en tenons à notre exemple, dans lequel nous souhaitons créer une version électronique carnet de notes, alors ci-dessous tous les composants nécessaires à sa mise en œuvre :

• Champ pour saisir de nouvelles entrées (événements, tâches, etc.).
• Bouton pour confirmer l'entrée saisie.
• Un bouton pour effacer une liste de tâches déjà créée.
• Une liste non ordonnée qui sera reconstituée avec des éléments sous forme de nouvelles entrées.
• Enfin, nous avons besoin d'un div en tant que conteneur contenant des messages à afficher à l'utilisateur, comme un avertissement indiquant qu'il a oublié de saisir la valeur de l'entrée suivante, laissant le champ de saisie vide.

En conséquence, notre balisage devrait ressembler à ceci :