27
SEP

Le stockage local en HTML5: localStorage

Publié le 27/09/10 à 08h23 par DJo

Avec la venue du HTML5, une nouvelle méthode de stockage des données est introduite: Le stockage local (localStorage).

stockage local en HTML5 avec localStorage

C'est sans doute l'une des prorpiétés les plus intéressantes du HTML5: Le local storage, ou le stockage local.

En effet, grâce à cette propriété, il sera désormais possible de stocker des données localement dans votre navigateur (supportant la propriété bien sûr).

Les données sont stockées pour un domaine précis et peuvent récupérées dans n'importe quelle page du domaine en question.

La propriété s'annonce comme le remplacement des cookies à la différence qu'il est possible de stocker bien plus d'informations (Environ 5 Mb) et que seul le client peut accéder à ces données.

Passons maintenant à la pratique en utilisant les fonctions dédiées:

 

Stocker une valeur locale (HTML5)

Il y'a deux façons de procéder pour stocker localement:

localStorage['maCle'] = "Ma valeur";

ou

localStorage.setitem("maCle", "Ma valeur");

 

Récupérer une valeur locale (HTML5)

Après avoir stocké une donnée, vous avez là aussi deux possibilités de la récupérer:

localStorage['maCle']

ou

localStorage.getitem['maCle']

Facile non ?

 

Tester si le navigateur supporte le localStorage

Comme vous avez pu le constater, nous utilisons l'objet localStorage en Javascript pour stocker en local. Il suffit donc de tester l'existance de l'objet pour vérifier si le navigateur supporte bien la propriété:

if (localStorage) {
  // Le navigateur supporte le localStorage
} else {
  // localStorage non supporté
}

 

Supprimer une valeur locale

Pour supprimer une des valeurs stockées:

removeItem("maCle");

 

Voilà, vous connaissez maintenant le béaba du localStorage HTML5, il ne vous reste plus qu'à l'appliquer !

Concernant les compatibilités navigateurs:

  • Firefox: 3.5
  • Chrome: 4+
  • Internet Explorer: 8+
  • Safari: 4+
  • Opera: 10.5+
  • iPhone: 2.0+
  • Android: 2.0+
Baraguiné par Spout le 27/09/10 à 08h58
Spout sur La Ferme du Web
"nous utiliser l'objet localStorage"
nous utilisons?
C'est très intéressant et carrément moins casse couille que les cookies. Mais vu la quantité de postes restant avec ie6, c'est pas demain la veille qu'on va utiliser cette techno souvent.
Baraguiné par Maraumax le 27/09/10 à 10h02
Maraumax sur La Ferme du Web
Qu'est ce qu'il y a de moins compliqué que les cookies ?
Baraguiné par naholyr le 27/09/10 à 10h10
naholyr via Twitter
Attention à une différence majeure, qui fait que ce n'est pas du tout le même usage : les cookies sont passés au serveur via un header HTTP, et leurs valeurs sont donc accessibles côté serveur (en PHP via $_COOKIE par exemple).

Ici ce n'est pas le cas, c'est purement local :) Ça a l'avantage indéniable de ne pas polluer les headers http avec des données inutiles, et vient donc plutôt en *complément* des cookies.
Cookie pour la communication de données persistentes avec le serveur.
localStorage pour le client-only.
Baraguiné par Cadrach le 27/09/10 à 10h17
Cadrach sur La Ferme du Web
Pour la compatibilité IE6, il existe une lib qui fallback toute seule sur userData (IE) si le localstorage n'est pas disponible.
jStorage. http://www.jstorage.info/

Elle s'adapte en plus au framework utilisé (prototype, MooTools ou jQuery)
Baraguiné par Helios le 27/09/10 à 10h35
Helios sur La Ferme du Web
Citation :
Mais vu la quantité de postes restant avec ie6, c'est pas demain la veille qu'on va utiliser cette techno souvent.

>> Il ne tient qu'aux développeurs de faire bouger les choses et d'arrêter de se saborder tout seuls.
Je suis pour utiliser au maximum les nouvelles possibilités de la techno web (si ça apporte quelque chose). Est-ce que les développeurs de jeux PC se limitent à des technos/équipements vieux de 10 ans? Non. Et l'utilisateur final s'adapte en conséquence. Là il suffit juste de prévenir l'utilisateur que son navigateur ne supporte pas la fonctionnalité et l'inviter à télécharger une version plus récente ou passer à un autre navigateur. C'est pas la mort et bien moins onéreux que changer son PC dépassé.

Après, pour ce qui est des sociétés/agences/gouvernements qui restent sur du IE6 (le plus gros frein) si les possibilités offertes leur sont présentées comme vraiment intéressantes, elles finiront par suivre.

Bien sûr il y a toujours le "oui mais on se ferme à une part du marché". Mais si cette part du marché se retrouve bloquée de partout, elle bougera pour finalement disparaitre.
Baraguiné par xam1311 le 27/09/10 à 11h05
xam1311 sur La Ferme du Web
Le souci des entreprises et institutionnels qui refusent de passer au dessus d'ie 6 n'est pas qu'ils sont rétrogrades , mais que beaucoup de web apps sont dev pour IE 6 et sans ce navigateur ça ne marchera plus pour eux , donc repenser la conception voir la refaire , donc beaucoup y vont avec bcp bcp de lenteur , et pour cause ...
Patience IE 6 est encore supporte jusqu'en 2014...
Baraguiné par Helios le 27/09/10 à 11h28
Helios sur La Ferme du Web
ça je sais bien hélas, je fais de la maintenance sur des applications intranet qui ne supportent pratiquement que IE6 et s'il fallait les migrer, ce serait dans la douleur et couterait pas mal pour pas grand chose (en tout cas dans l'esprit du client).
Mais il n'empêche que si un nouveau projet devais voir le jour et que j'en ai la responsabilité, je ferais tout pour qu'ils lâchent IE6, quittes à devoir utiliser 2 navigateurs, un pour les vieilles applis et un plus récent.

Sinon pour en revenir au sujet initial du local storage, je suis content de voir que c'est aussi simple à utiliser que le stockage de variables Greasemonkey.
Baraguiné par BoiteAWeb le 27/09/10 à 14h49
BoiteAWeb via Twitter
Et niveau sécurité ça va donner quoi tout ça ?
Baraguiné par themax le 28/09/10 à 00h12
themax sur La Ferme du Web
non mais les gars on va arrêter l'éternel débat autour d'IE6. Si vous allez à la station service avec votre cheval, ils servent plus de foin.

On va pas éternellement rester sur un navigateur d'avant guerre. C'est quoi l'excuse pour Schneider Electric et Air liquide de pas mettre à jour leur navigateur ? L'admin en a pour 5 minutes franchement.

" que beaucoup de web apps sont dev pour IE 6 " : n'est pas une excuse. Ce genre d'app d'une autre époque coutent une fortune et ne sont jamais mises à jour. Les neuneus (d'anciens R
Baraguiné par williamode le 28/09/10 à 13h42
williamode via Twitter
Donc plus clairement ça veut dire quoi? Qu'on freine complètement l'innovation à cause de vieilles applis pourries qui ne tournent que sous IE6? Pourquoi ne pas mettre à jour l'ensemble de ces vieilles applications plutôt que d'imposer un navigateur qui freine toute nouveauté et obligent les intégrateurs et développeurs à jouer avec leurs nerfs?
Soyons un peu logiques, que diable!
Baraguiné par Helios le 28/09/10 à 17h39
Helios sur La Ferme du Web
Pourquoi ne pas mettre à jour les applis IE6 ? La réponse tient en un seul mot : argent.

Rendre une appli IE6 compatible avec les navigateurs récents va souvent s'avérer complexe et coûteux en temps de développement (il faut notamment revalider le fonctionnement de TOUTE l'application), donc en argent. Tout ce que veux le client généralement c'est que ça fonctionne. Et si ça fonctionne sous IE6, il ne verra pas l'intérêt de dépenser de l'argent "pour rien". Quand tu as non pas une mais des dizaines d'applis (qui ont coûtées chacune des dizaines de milliers d'euros) qui ne sont pas compatibles et que certaines sont même critiques dans la stratégie de l'entreprise, l'entreprise préfère ne pas toucher car elle n'y voit aucun intérêt et reste donc sous IE6 et ses employés qui vont un peu sur le net (pas que pour flâner, mais pour le boulot aussi) restent bloqués sous IE6.
Rien que pour faire migrer d'une version de PHP à une autre même mineure ça prend des plombes.

C'est pourquoi j'encourage vivement à utiliser les nouvelles technos web, sans fallback, rétrocompatibilité ou autre saloperie, pour obliger l'utilisateur à bouger. Et les nouveautés de HTML5 l'harmonisation de rendu des nouveaux navigateurs s'annoncent enfin comme des arguments de poids pour ça.


PS: les vieilles applis ne sont pas forcément pourries, même si elles ne sont conçues que pour IE6 ;-)
Baraguiné par Nath le 29/09/10 à 07h49
Nath sur La Ferme du Web
De toutes façons, dans les grosses boites boites qui restent coincées sur IE6, il est généralement interdit de surfer, en dehors du microcosme de la boite.
Sinon, il leur suffirait effectivement d'avoir 2 navigateurs : 1 pour les vieilles-applis-intouchables, l'autre pour le "vrai" web.

Par contre, c'est vrai aussi qu'il y a des gens qui reste sous IE (7 généralement) parce qu'il ne savent pas qu'il existe autre chose, ni comment changer. Ou encore, ne savent pas pourquoi ils changeraient puisque ça marche...
Baraguiné par le 16/04/12 à 18h48
Bonjour,
Merci beaucoup pour l'explication , je développe un jeu en HTML5 donc je dois stocker pour chaque joueur sa dernière progression de jeu donc il sera capable de terminer le jeu jusqu?a la fin .
est-ce que je peux le faire avec un LocalStorage ou non : donc je dois stocker aussi le nom du joueur ?
Baraguiné par Gaudac le 05/03/13 à 14h06
Gaudac sur La Ferme du Web
Bonjour,

j'ai conscience de remonter un post datant d'un an, mais je précise pour les personnes étant dans le même cas qu'Amira Mannai :

Tu peux effectivement stocker la progression du jeu grâce à un LocalStorage, mais il faut savoir que les données peuvent être facilement effacées.
S'il s'agit d'un jeu où les personnes doivent être connectées, il est bien entendu préférable d'insérer les paramètres sauvegardés dans une Base de Données.

Personnellement, je trouve l'utilisation de "LocalStorage" relativement limitée et comme précisé quelques posts au-dessus, cette fonction ne remplacera jamais les Cookies étant donné qu'elle s?exécute côté client.
Baraguiné par Doume65 le 07/01/16 à 13h17
Doume65 sur La Ferme du Web
Bonjou et merci pour ce tuto.
Le petit test que vous avez rédigé « if(localStorage)[...] » concernant la vérification du support de la propriété localStorage n’est pas écrit correctement.
Vous oubliez de dire que cette propriété est rattachée à l’objet window.
Si le test que vous avez proposé est appliqué alors que le navigateur ne l’implémente pas, vous levez une exception, et le reste du code n’est pas exécuté. En bref, le script est bloqué. Pour remédier à cela, on doit indiquer l’objet supposé supporter cette propriété : « if(self.localStorage)[...] »
Et là, le test fonctionnera même si la propriété n’est pas supportée et la suite sera bien exécutée.
Si vous pouvez corriger...

Ajouter un Commentaire

Pour poster un commentaire, vous devez être identifié. Vous pouvez choisir parmi ces trois méthodes d'identification:

Compte la Ferme du Web

Identifiez-vous
Inscrivez-vous

Compte Facebook

Connexion avec Facebook

Compte Twitter

Connexion avec votre compte twitter
Rechercher sur la Ferme du web