Stockage local des cookies. Stockage local. Opérations CRUD de base avec stockage local

Aperçu Web Stockage

Sur Internet, les informations peuvent être stockées à deux endroits : sur le serveur Web et sur le client Web (c'est-à-dire l'ordinateur du visiteur de la page). Certains types de données sont mieux stockés dans l'un de ces endroits, et d'autres types dans un autre.

Le bon endroit pour stocker des données sensibles et importantes serait un serveur Web. Par exemple, si vous ajoutez des articles à votre panier dans une boutique en ligne, les détails de vos achats potentiels sont stockés sur un serveur Web. Seuls quelques octets de données de suivi sont stockés sur votre ordinateur, contenant des informations sur vous (ou plutôt, votre ordinateur), afin que le serveur Web sache quel bac est le vôtre. Même avec les nouvelles fonctionnalités de HTML5, il n'est pas nécessaire de modifier ce système - il est fiable, sécurisé et efficace.

Mais stocker des données sur le serveur n'est pas toujours la meilleure approche, car il est parfois plus facile de stocker des informations non essentielles sur l'ordinateur de l'utilisateur. Par exemple, il est judicieux de stocker localement les paramètres de l'utilisateur (par exemple, les paramètres qui déterminent l'affichage d'une page Web) et l'état de l'application (instantané état actuel application web) afin que le visiteur puisse poursuivre ultérieurement son exécution depuis le même endroit.

Avant HTML5, la seule façon de stocker des données localement était d'utiliser le mécanisme de fichier. biscuits, initialement conçu pour échanger de petites quantités d'informations d'identification entre les serveurs Web et les navigateurs. Les cookies sont idéaux pour stocker de petites quantités de données, mais le modèle JavaScript pour travailler avec eux est un peu maladroit. Le système de cookies oblige également le développeur à manipuler les dates d'expiration et à envoyer inutilement des données sur Internet à chaque demande de page.

HTML5 introduit une meilleure alternative aux cookies, ce qui permet de stocker facilement et simplement des informations sur l'ordinateur d'un visiteur. Ces informations peuvent être stockées sur ordinateur client indéfiniment, non envoyé à un serveur Web (à moins que le développeur ne le fasse lui-même), peut être volumineux et ne nécessite que quelques objets JavaScript simples et efficaces pour fonctionner.

Cette possibilité est appelée stockage Web (stockage Web) et est particulièrement adapté pour une utilisation avec mode hors-ligne le travail des sites Web, car vous permet de créer des applications autonomes autonomes qui peuvent enregistrer toutes les informations dont elles ont besoin même lorsqu'il n'y a pas de connexion Internet.

La fonctionnalité de stockage Web HTML5 permet à une page Web de stocker des données sur l'ordinateur du visiteur. Ces informations peuvent être à court terme, qui sont supprimées lorsque le navigateur est éteint, ou à long terme, qui restent disponibles lors de visites ultérieures sur la page Web.

Les informations stockées dans le stockage Web ne sont pas réellement stockées sur Internet, mais sur l'ordinateur du visiteur de la page Web. En d'autres termes, le stockage Web signifie stocker des données non pas sur Internet, mais stocker des données à partir d'Internet.

Il existe deux types de stockage Web qui sont liés à deux objets d'une manière ou d'une autre :

Utilise l'objet stockage local pour stocker des données pour l'ensemble du site Web sur sur base permanente. Cela signifie que si une page Web enregistre des données sur le stockage local, ces données seront disponibles pour l'utilisateur lorsqu'il reviendra sur cette page Web le lendemain, la semaine prochaine ou l'année prochaine.

Bien sûr, la plupart des navigateurs offrent également à l'utilisateur la possibilité d'effacer le stockage local. Il est implémenté comme une stratégie tout ou rien dans certains navigateurs, et il supprime toutes les données locales, tout comme les cookies sont supprimés. (En fait, dans certains navigateurs, le système de cookies et le stockage local sont interconnectés, de sorte que la seule façon de supprimer les données locales est de supprimer les cookies.) Et d'autres navigateurs peuvent offrir à l'utilisateur la possibilité d'afficher les données de chaque site Web individuel et de supprimer données pour le ou les sites sélectionnés.

Utilise l'objet sessionStorage pour stocker temporairement des données pour une seule fenêtre ou un seul onglet de navigateur. Ces données ne sont disponibles que jusqu'à ce que l'utilisateur ferme la fenêtre ou l'onglet, auquel cas la session se termine et les données sont supprimées. Mais les données de session sont conservées si l'utilisateur navigue vers un autre site Web, puis revient, tant que cela se produit dans la même fenêtre de navigateur.

Du point de vue du code de la page Web, le stockage local et le stockage des données de session fonctionnent exactement de la même manière. La différence réside uniquement dans la durée de stockage des données.

L'utilisation du stockage local offre la meilleure opportunité de stocker les informations requises pour les visites ultérieures de la page Web par l'utilisateur. Et le magasin de session est utilisé pour stocker les données qui doivent être transférées d'une page à l'autre. (Le stockage de session peut également stocker des données temporaires utilisées uniquement sur une page, mais les variables JavaScript normales fonctionnent parfaitement à cette fin.)

Le stockage local et le stockage de session sont associés au domaine d'un site Web. Ainsi, si vous enregistrez les données de la page www..html dans le stockage local, ces données seront disponibles pour la page www..html, car ces deux pages ont le même domaine. Mais ces données ne seront pas disponibles pour les pages d'autres domaines.

De plus, depuis le stockage Web est situé sur un ordinateur (ou appareil mobile) cet utilisateur, il est associé à cet ordinateur et la page Web ouverte sur cet ordinateur et stockant des données dans son stockage local, n'a pas accès aux informations qu'il a stockées sur un autre ordinateur. De même, une page Web crée un stockage local séparé si vous vous connectez avec un nom d'utilisateur différent ou lancez un navigateur différent.

Bien que la spécification HTML5 ne fixe aucune règle absolue concernant la quantité maximale de stockage, la plupart des navigateurs la limitent à 5 Mo. Beaucoup de données peuvent être regroupées dans cette quantité, mais cela ne suffira pas si vous souhaitez utiliser le stockage local pour optimiser les performances et y mettre en cache de grandes images ou vidéos (et, pour dire la vérité, le stockage local n'est pas destiné à de telles fins).

Pour stocker de grandes quantités de données, une norme de base de données en constante évolution IndexedDB permet un stockage local beaucoup plus important - généralement 50 Mo pour commencer, et plus si l'utilisateur est d'accord.

La sauvegarde des données

Avant qu'une information puisse être placée dans le stockage local ou de session, il faut lui donner un nom descriptif. Ce nom s'appelle une clé (clé) et est nécessaire pour que les données puissent être récupérées à l'avenir.

La syntaxe de sauvegarde d'une donnée est la suivante :

stockage local = données ;

// JS localStorage["nom d'utilisateur"] = "Ivan Petrov" ;

Bien sûr, enregistrer un morceau de texte statique n'a pas de sens. En règle générale, nous devons stocker certaines données variables, telles que la date actuelle, le résultat d'un calcul mathématique ou des données textuelles saisies par l'utilisateur dans les champs du formulaire. Voici un exemple d'enregistrement de données textuelles saisies par l'utilisateur :

Fonction saveData() ( // Récupère les valeurs du champ de texte var localData = document.getElementById("localData"). value; var sessionData = document. getElementById("sessionData"). value; // Enregistre le texte saisi dans le champ de texte vers le stockage local localStorage["localData"] = localData; // Stocke le texte saisi dans le champ de texte dans le stockage de session sessionStorage["sessionData"] = sessionData; ) function loadData() ( // Charge les données stockées à partir de les stockages var localData = localStorage ["localData"]; var sessionData = sessionStorage["sessionData"]; // Afficher ces données dans des champs de texte if (localData != null) ( document.getElementById("localData").value = localData ; ) si (sessionData ! = null) ( document.getElementById("sessionData").value = sessionData; ) )

La page contient deux champs de texte : un pour le stockage local (en haut) et un pour le stockage de session (en bas). Cliquer sur le bouton "Enregistrer" enregistre le texte saisi dans les champs de texte, et cliquer sur le bouton "Charger" affiche les données enregistrées correspondantes dans les champs.

Web Storage prend également en charge la syntaxe de propriété moins courante. Selon les règles de cette syntaxe, nous nous référons à l'emplacement de stockage nommé nom d'utilisateur comme localStorage.username, et non localStorage["username"]. Les deux types de syntaxe sont équivalents et l'utilisation de l'un ou de l'autre est une question de préférence personnelle.

Le stockage Web ne fonctionne pas sans serveur Web

Dans votre recherche de stockage Web, vous pouvez rencontrer un problème inattendu. Dans de nombreux navigateurs, le stockage Web ne fonctionne que pour les pages fournies par le serveur Web. Peu importe où se trouve le serveur, sur Internet ou sur votre propre ordinateur, le plus important est que les pages ne soient pas lancées depuis le local disque dur(par exemple, en double-cliquant sur l'icône de fichier de la page).

Cette fonctionnalité est un effet secondaire de la façon dont les navigateurs allouent de l'espace au stockage local. Comme indiqué précédemment, les navigateurs limitent le stockage local par site Web à 5 Mo, ce qui les oblige à associer chaque page qui souhaite utiliser le stockage local au domaine du site Web.

Que se passe-t-il si vous ouvrez une page qui utilise le stockage Web à partir de votre disque dur local ? Tout dépend du navigateur. navigateur Internet Explorer semble perdre complètement la prise en charge du stockage Web. Les objets localStorage et sessionStorage disparaissent et essayer de les utiliser provoque une erreur JavaScript.

À Navigateur Firefox les objets localStorage et sessionStorage restent en place et semblent être pris en charge (même Modernizr détermine ce qui est pris en charge), mais tout ce qui est envoyé au stockage disparaît sans que personne ne sache où. À Navigateur Chrome encore une fois, quelque chose d'autre - la plupart des fonctionnalités de stockage Web fonctionnent comme il se doit, mais certaines fonctionnalités (comme l'événement onStorage) ne fonctionnent pas.

Des problèmes similaires surviennent avec l'utilisation de l'API File. Par conséquent, vous vous épargnerez bien des ennuis si vous mettez la page que vous testez sur un serveur de test pour éviter toutes ces incertitudes.

Prise en charge du stockage Web par les navigateurs

Le stockage Web est l'une des fonctionnalités les plus prises en charge de HTML5, avec un bon niveau de prise en charge dans tous les principaux navigateurs. Le tableau ci-dessous répertorie les versions minimales des principaux navigateurs prenant en charge le stockage Web :

Tous ces navigateurs fournissent un stockage local et un stockage des données de session. Cependant, la prise en charge de l'événement onStorage nécessite des navigateurs plus récents tels que IE 9, Firefox 4 ou Chrome 6.

La version la plus problématique est IE 7, qui ne prend pas du tout en charge le stockage Web. Pour contourner le problème, vous pouvez émuler le stockage Web à l'aide de cookies. Ce n'est pas exactement une solution parfaite, mais cela fonctionne. Bien qu'il n'y ait pas de script officiel pour combler cette lacune, quelques bons points de départ peuvent être trouvés sur la page HTML5 Cross Browser (sous "Web Storage").

La 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 dans Web Storage sont les suivants :

• sessionStorage maintient une zone de stockage distincte pour chaque origine donnée qui est disponible pendant la durée de la session de la 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'à ce que le navigateur (ou l'onglet) soit fermé.
  • Les données ne sont jamais transférées au serveur.
  • La limite de stockage est plus grande qu'un cookie (au plus 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 demande d'extraction.

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

Légende

Modes de navigation privée / Incognito

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 les données telles que 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érents scénarios sur la façon de gérer cette incompatibilité.

La plupart des navigateurs ont opté pour une stratégie où 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 qu'il convient de faire avec les données stockées existantes (à partir d'une session de navigation normale). Doit-il être disponible en lecture en mode privé ? Ensuite, il y a certains navigateurs, notamment Safari, qui ont opté pour une solution où le stockage est disponible, mais est vide et a un quota de 0 octet attribué, ce qui rend effectivement impossible l'écriture de données dessus.

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 de blog WHATWG qui traite spécifiquement de ce sujet.

Traduction : Vlad Merzhevich

Le stockage local persistant est un domaine dans lequel les applications client présentent des avantages par rapport aux applications serveur. Pour des applications comme 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, des fichiers INI, des fichiers XML ou ailleurs, selon les principes de la plate-forme. 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, proposer votre propre format de fichier ou un certain nombre d'autres solutions.

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 ont trois inconvénients potentiels :

• des cookies sont inclus avec chaque requête HTTP, ralentissant ainsi votre application Web en envoyant inutilement les mêmes données encore et encore ;
• les cookies sont inclus dans chaque requête HTTP lorsque les données sont transmises sur Internet sous une 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 - assez pour ralentir votre application (voir ci-dessus), mais pas assez pour être utiles.

Voici ce que nous voulons vraiment :

• beaucoup d'espace de rangement;
• travailler côté client;
• envisager d'actualiser la page ;
• pas d'envoi au serveur.

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

Un bref historique du stockage local avant HTML5

Au début, il n'y avait qu'un seul Internet Explorer. Au moins, Microsoft voulait que le monde le pense. À cette fin, dans le cadre de la première grande guerre des 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'appelle DHTML Behaviors et l'un des comportements s'appelle 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 stocker dix fois plus. Et bon, 640kb 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 mémoire disponible.

En 2002, Adobe a introduit une fonctionnalité dans Flash 6 qui a été infructueuse et nommée de manière trompeuse "Flash cookies". À Environnement Flash cette capacité est plus correctement connue sous le nom d'objets partagés locaux (objets accessibles locaux, LSO). En bref, il permet aux objets Flash de stocker jusqu'à 100 Ko de données par domaine. Brad Neuberg a développé un premier prototype d'un pont entre Flash et JavaScript appelé AMASS (AJAX Massive Storage System), mais il était limité par certaines bizarreries de conception Flash. En 2006, avec l'avènement d'ExternalInterface dans Flash 8, l'accès au LSO via JavaScript était devenu d'un ordre de grandeur plus facile et plus rapide. Brad a réécrit AMASS et l'a intégré dans le populaire Dojo Toolkit sous l'alias dojox.storage . Flash "gratuit" donne à chaque domaine 100 ko de stockage. De plus, il invite l'utilisateur à augmenter la quantité de stockage d'un ordre de grandeur (1 Mo, 10 Mo, etc.) sur demande.

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

Utiliser le stockage HTML5

Le stockage HTML5 est basé sur les noms des paires clé/valeur. Vous stockez des informations basées sur un nom de 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, y compris des chaînes, des booléens, des entiers ou des nombres à virgule flottante. Cependant, les données sont en fait stockées sous forme de chaîne. Si vous ne stockez pas et ne récupérez pas de chaînes, vous devrez utiliser des fonctions telles que parseInt() ou parseFloat() pour traduire les données reçues dans les types JavaScript corrects.

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

Appeler setItem() avec un nom de clé existant écrasera silencieusement la valeur précédente. Appeler 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 utiliser des crochets. Par exemple ce bout de code

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

peut être réécrit en utilisant la syntaxe des 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 tout le magasin (c'est-à-dire supprimer toutes les clés et valeurs à la fois).

Interface de stockage (
Supprimer via removeItem(key);
dégager();
}

Appeler removeItem() avec une clé qui n'existe pas ne renverra rien.

Enfin, il existe une propriété permettant d'obtenir le nombre total de valeurs dans la zone de stockage et d'itérer sur toutes les clés par index (obtient le nom de chaque clé).

Interface de stockage (
longueur
Get key (entier non négatif);
}

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

Suivi de la zone de stockage HTML5

Si vous souhaitez suivre les modifications de stockage par programmation, vous devez intercepter l'événement de stockage. Cet événement est déclenché sur l'objet window lorsque setItem() , removeItem() ou clear() sont appelés et changent quelque chose. Par exemple, si vous définissez valeur existante ou appelez 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 est en cours d'exécution, y compris Internet Explorer 8. IE 8 ne prend pas en charge la norme W3C addEventListener (bien qu'il sera finalement ajouté dans IE 9), donc pour intercepter l'événement de stockage, vous devez vérifier quel mécanisme d'événement il prend en charge le navigateur (si vous l'avez déjà fait avec d'autres événements, vous pouvez ignorer cette section jusqu'à la fin). 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 un objet StorageEvent, sauf dans Internet Explorer, où les événements sont stockés dans window.event .

fonction handle_storage(e) (
if (!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 le changement de spécification. Pour une compatibilité maximale, vous devez vérifier si la propriété url existe, et si ce n'est pas le cas, vérifiez plutôt la propriété uri.

L'événement de stockage ne peut pas être annulé, il n'y a aucun moyen dans le rappel handle_storage d'arrêter le changement. C'est juste la façon dont le navigateur vous dit : "Hé, ça vient d'arriver. Tu ne peux rien faire, je voulais juste que tu saches."

Limitations dans les navigateurs actuels

Parlant de l'histoire du stockage local avec des plugins tiers, j'ai mentionné les limites de chaque technique. Je me suis souvenu que je n'avais rien dit sur les limitations du stockage HTML5 désormais standard. Je vais vous donner les réponses et ensuite je vous les expliquerai. 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 donné par défaut. Cette valeur est étonnamment la même dans tous les navigateurs, même si elle n'est formulée que comme une suggestion dans la spécification HTML5. Vous devez comprendre que vous stockez des chaînes, et non des données dans leur 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é en tant que caractère, et non dans la représentation habituelle de ces nombres.

"QUOTA_EXCEEDED_ERR" est l'exception que vous obtenez 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 cela est purement à l'initiative de l'utilisateur et n'a rien à voir avec ce que vous, en tant que développeur, pouvez intégrer à votre application Web.

Stockage HTML5 en action

Jetons un coup d'œil au stockage HTML5 en action. Revenons à celui que nous avons construit dans le chapitre dessin. Il y a un petit problème avec ce jeu : si vous fermez la fenêtre du navigateur au milieu du jeu, vous perdrez les résultats. Mais avec le stockage HTML5, nous pouvons enregistrer le jeu en place, 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 votre 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 a un changement dans le jeu, nous appellerons cette fonction.

fonction saveGameState() (

localStorage["halma.game.in.progress"] = gGameInProgress ;
pour (var i = 0; je< kNumPieces; i++) {
localStorage["halma.morceau." + je + ".row"] = gPièces[i].row;
localStorage["halma.morceau." + i + ".column"] = gPieces[i].column ;
}
localStorage["halma.selectedpiece"] = gSelectedPieceIndex ;
localStorage["halma.selectedpiecehasmoved"] = gSelectedPieceHasMoved ;
localStorage["halma.movecount"] = gMoveCount ;
retourner vrai ;
}

Comme vous pouvez le voir, l'objet localStorage est utilisé pour enregistrer la progression du jeu (gGameInProgress , booléen). Ensuite, itère sur toutes les puces (gPieces , un tableau JavaScript) et stocke une ligne et une colonne pour chacune. Après cela, certains états de jeu supplémentaires sont stockés, y compris la pièce actuellement sélectionnée (gSelectedPieceIndex , un entier), la pièce qui se trouve au milieu d'une longue série de sauts (gSelectedPieceHasMoved , booléen) et nombre total coups effectués (gMoveCount , entier).

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

fonction resumeGame() (
if (!supportsLocalStorage()) ( renvoie faux; )
gGameInProgress = (localStorage["halma.game.in.progress"] == "true");
if (!gGameInProgress) ( renvoie faux; )
gPieces = new Array(kNumPieces);
pour (var i = 0; je< kNumPieces; i++) {
var row = parseInt(localStorage["halma.piece." + i + ".row"]);
var colonne = parseInt(localStorage["halma.piece." + i + ".column"]);
gPieces[i] = new Cell(ligne, colonne);
}
gNumPieces = kNumPieces ;
gSelectedPieceIndex = parseInt(localStorage["halma.selectedpiece"]);
gSelectedPieceHasMoved = localStorage["halma.selectedpiecehasmoved"] == "true" ;
gMoveCount = parseInt(localStorage["halma.movecount"]);
drawBoard();
retourner vrai ;
}

La partie la plus importante de cette fonctionnalité est la 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 obtiendrez. Par exemple, l'indicateur de jeu en cours (gGameInProgress) est un 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 resumeGame(), nous devons considérer la valeur extraite du stockage local comme une 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 l'enregistrons simplement.

localStorage["halma.movecount"] = gMoveCount ;

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

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

Au-delà du couple clé/valeur : vision concurrentielle

Bien qu'il y ait eu de nombreuses astuces et solutions de contournement dans l'histoire, l'état actuel du stockage HTML5 est étonnamment sûr. La nouvelle API a été standardisée et incluse dans tous les principaux navigateurs, plates-formes et appareils. Pour un développeur Web, vous ne voyez pas cela tous les jours, n'est-ce pas ? Mais c'est plus que "5 mégaoctets de paires clé/valeur" et l'avenir du stockage local persistant est... comment dire... eh bien, 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 inclut une base de données intégrée basée sur SQLite. Ce premier prototype a ensuite influencé la création de la spécification Web SQL Database. Web SQL Database (anciennement connu sous le nom de « WebDB ») fournit une enveloppe mince 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 des documents", 5*1024*1024, fonction (db) (
db.changeVersion("", "1.0", fonction (t) (
t.executeSql("CREATE TABLE docids (id, name)");
), Erreur);
});

Comme vous pouvez le voir, la plupart des actions sont en ligne avec la méthode ExecuteSQL. Cette chaîne peut prendre en charge n'importe quelle commande SQL, y compris SELECT, UPDATE, INSERT et DELETE. C'est 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'une norme stricte et rapide (on pourrait dire la même chose à propos de HTML5, mais ce n'est pas important). Bien sûr, il existe une véritable spécification SQL (elle s'appelle SQL-92), mais aucun serveur de base de données au monde ne se conforme uniquement à cette spécification. Il y a 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, il ne suffit donc pas de dire simplement "SQL dans SQLite". Vous devez dire "la version de SQL fournie avec la version SQLite X.Y.Z".

Tout cela nous amène à la mise en garde suivante, actuellement placée au sommet 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 avancer sur la voie de la normalisation. Alors que d'autres développeurs sont intéressés par l'implémentation de cette spécification, la description du dialecte SQL a été laissée comme une simple référence à Sqlite, ce qui n'est pas accepté par 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 de base de données indexée fournit ce qu'on appelle un magasin 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 a un certain nombre de "champs". Chaque champ a un type de données spécifique, qui est défini lors de la création de la base de données. Vous pouvez sélectionner une partie des entrées, 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 d'objets n'a pas de langage de requête structuré. Vous n'écrivez pas une condition comme "SELECT * from USERS where 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 guide sur le fonctionnement d'IndexedDB et comment IndexedDB se compare à Web SQL.

Au moment de la rédaction, 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émentera jamais Web SQL. Google a déclaré qu'il envisageait de prendre en charge IndexedDB pour Chromium et Google Chrome. Et même Microsoft a déclaré qu'IndexedDB est "une excellente solution pour le Web".

Que pouvez-vous faire en tant que développeur Web avec IndexedDB ? Pour l'instant, presque rien, si ce n'est quelques démonstrations technologiques. Dans un an? Peut-être.

Dernière mise à jour : 1.11.2015

Bien que les cookies permettent de stocker des informations, ils présentent un certain nombre de limitations. Par exemple, le navigateur a des restrictions sur la taille des cookies - chaque cookie ne peut pas dépasser 4 ko. Les cookies ont une date d'expiration après laquelle ils sont supprimés. Les cookies font partie intégrante du protocole HTTP et sont transmis avec chaque demande au serveur avec la demande au serveur. Cependant, pour travailler avec des cookies côté client dans du code javascript, la transmission de cookies au serveur n'a pas d'importance. De plus, pour récupérer les cookies stockés, vous devez écrire du code.

Par conséquent, HTML5 a introduit nouveau concept pour le stockage de données - stockage Web. Le stockage Web se compose de deux composants : le stockage de session et le stockage local .

Le stockage de session est un stockage temporaire d'informations qui sont supprimées après la fermeture du navigateur.

Le stockage local représente le stockage des données sur une base continue. Les données du stockage local ne sont pas automatiquement supprimées et n'expirent pas. Ces données ne sont pas envoyées au serveur dans une requête HTTP. De plus, la quantité de stockage local dans Chrome et Firefox est de 5 Mo pour un domaine, et dans IE - 10 Mo.

Toutes les données du stockage Web sont un ensemble de paires clé-valeur. Autrement dit, chaque objet a un nom de clé unique et une valeur spécifique.

Pour travailler avec le stockage local en javascript, l'objet localStorage est utilisé, et pour travailler avec le stockage de session, l'objet sessionStorage est utilisé.

Pour enregistrer les données, transmettez-les à la méthode setItem() de l'objet localStorage :

LocalStorage.setItem("connexion", " [courriel protégé]");

Deux valeurs sont passées à cette méthode : la clé et la valeur de l'objet à sauvegarder.

Si localStorage a déjà un objet avec la clé "login", alors sa valeur est remplacée par une nouvelle.

Pour obtenir les données enregistrées, vous devez appeler la méthode getItem() :

var login = localStorage.getItem("login"); // [courriel protégé]

La clé de l'objet est passée à cette méthode.

Pour supprimer un objet, utilisez la méthode removeItem(), qui prend la clé de l'objet à supprimer :

LocalStorage.removeItem("connexion");

Et pour suppression complète de tous les objets de localStorage, vous pouvez utiliser la méthode clear() :

LocalStorage.clear();

L'enregistrement d'objets simples est simple, mais gardez à l'esprit que les données dans localStorage sont stockées sous forme de chaîne :

LocalStorage.setItem("âge", 23); var age = localStorage.getItem("age"); âge=parseInt(âge)+10 ; document.write(age); //33

Si, dans ce cas, la valeur n'est pas convertie en nombre à l'aide de parseInt() , alors age agira comme une chaîne.

Des difficultés peuvent survenir lors de la sauvegarde d'objets complexes :

Var user =( nom : "Tom", âge : 23 ans, marié : false ); localStorage.setItem("utilisateur", utilisateur); var saveUser = localStorage.getItem("user"); document.write(savedUser); // document.write(savedUser.name); // non défini - l'utilisateur enregistré est une chaîne, pas un objet

Dans ce cas, nous devons utiliser la sérialisation JSON :

Var user =( nom : "Tom", âge : 23 ans, marié : false ); localStorage.setItem("utilisateur", JSON.stringify(utilisateur)); var saveUser = JSON.parse(localStorage.getItem("user")); document.write(savedUser.name + " + savedUser.age +" " + savedUser.married ); // Tom 23 faux