LocalStorage.getItem('item') est-il préférable à localStorage.item ou localStorage['item'] ?

Question

J'ai récemment demandé une question sur LocalStorage . Utilisation de JSON.parse(localStorage.item) y JSON.parse(localStorage['item']) ne travaillaient pas pour revenir NULL alors que l'élément n'avait pas encore été défini.

Cependant, JSON.parse(localStorage.getItem('item') a fonctionné. Et il s'avère que, JSON.parse(localStorage.testObject || null) fonctionne également.

Un des commentaires a dit en gros que localStorage.getItem() y localStorage.setItem() devrait toujours être préférée :

Le getter et le setter fournissent une méthode cohérente, standardisée et efficace pour le traitement des données. et compatible avec tous les navigateurs pour travailler avec l'api LS. être préféré aux autres moyens. - Christoph

J'ai fini par aimer utiliser les notations abrégées point et parenthèse pour localStorage, mais je suis curieux de connaître l'avis des autres sur ce sujet. LocalStorage.getItem('item') est-il préférable à localStorage.item ou localStorage['item'] OU, dans la mesure où elles fonctionnent, les notations abrégées sont-elles acceptables ?

Answer 1

Les deux accès directs à la propriété ( localStorage.foo o localStorage['foo'] ) et l'utilisation de l'interface fonctionnelle ( localStorage.getItem('foo') ) fonctionnent bien. Les deux sont standard et compatibles avec tous les navigateurs. * Selon la spécification :

Les noms de propriété pris en charge sur un objet Storage sont les clés de chaque paire clé/valeur actuellement présente dans la liste associée à l'objet, dans l'ordre où les clés ont été ajoutées en dernier à la zone de stockage.

Ils se comportent simplement différemment lorsqu'aucune paire clé/valeur n'est trouvée avec le nom demandé. Par exemple, si la clé 'foo' n'existe pas, var a = localStorage.foo; aura pour résultat a être undefined alors que var a = localStorage.getItem('foo'); aura pour résultat a ayant la valeur null . Comme vous l'avez découvert, undefined y null ne sont pas interchangeables en JavaScript :)

EDIT : Comme le souligne Christoph dans sa réponse l'interface fonctionnelle est le seul moyen de stocker et d'extraire de manière fiable des valeurs sous des clés égales aux propriétés prédéfinies de l'interface utilisateur. localStorage . (Il y en a six : length , key , setItem , getItem , removeItem y clear .) Ainsi, par exemple, la formule suivante fonctionnera toujours :

localStorage.setItem('length', 2);
console.log(localStorage.getItem('length'));

Notez en particulier que la première déclaration n'affectera pas la propriété localStorage.length (sauf peut-être en l'incrémentant s'il n'y avait pas de clé 'length' déjà en place localStorage ). À cet égard, la spécification semble être incohérente sur le plan interne.

Cependant, ce qui suit ne fera probablement pas ce que vous voulez :

localStorage.length = 2;
console.log(localStorage.length);

Il est intéressant de noter que le premier est un no-op dans Chrome, mais est synonyme d'appel fonctionnel dans Firefox. Le second enregistrera toujours le nombre de touches présentes dans le fichier localStorage .

* _{Ceci est vrai pour les navigateurs qui prennent en charge le stockage web en premier lieu. () Pour les environnements qui simulent le stockage local à l'aide de cookies ou d'autres techniques, le comportement dépend de la cale utilisée. Plusieurs polyfills pour <code>localStorage</code> peuvent être trouvés <a href="https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-Browser-Polyfills" rel="nofollow noreferrer">aquí </a>.}

Answer 2

La question est déjà assez ancienne, mais puisque j'ai été cité dans la question, je pense que je devrais dire deux mots sur ma déclaration.

L'objet de stockage est assez spécial, c'est un objet qui donne accès à une liste de paires clé/valeur. Il ne s'agit donc pas d'un objet ou d'un tableau ordinaire.

Par exemple, il possède l'attribut length, qui contrairement à l'attribut array length est en lecture seule et renvoie le nombre de clés dans le stockage.

Avec un tableau, vous pouvez le faire :

var a = [1,2,3,4];
a.length // => 4
a.length = 2;
a // => [1,2]

Nous avons ici la première raison d'utiliser les getters/setters. Et si vous voulez définir un élément appelé length ?

localStorage.length = "foo";
localStorage.length  // => 0
localStorage.setItem("length","foo");
// the "length" key is now only accessable via the getter method:
localStorage.length  // => 1
localStorage.getItem("length") // => "foo"

Avec les autres membres de l'objet Storage, c'est encore plus critique, car ils sont accessibles en écriture et vous pouvez accidentellement écraser des méthodes telles que getItem . L'utilisation des méthodes de l'API permet d'éviter tous ces problèmes éventuels et fournit une interface cohérente.

Un autre point intéressant est le paragraphe suivant dans la spécification (souligné par moi) :

Les méthodes setItem() et removeItem() doivent être atomiques en ce qui concerne l'échec. En cas d'échec, la méthode ne fait rien. En d'autres termes, les modifications apportées à la zone de stockage des données doivent soit réussir, soit ne pas être modifiées du tout.

Théoriquement, il ne devrait pas y avoir de différence entre les getters/setters et les [] accès, mais on ne sait jamais...

Answer 3

Je sais que c'est un vieux post mais comme personne n'a mentionné les performances, j'ai mis en place des tests JsPerf pour les évaluer et, en plus d'être une interface cohérente, je trouve que les performances sont très bonnes. getItem y setItem sont également plus rapides que la notation par points ou les parenthèses et sont beaucoup plus faciles à lire.

Voici mes tests sur JsPerf

Answer 4

Comme il a été mentionné, il n'y a pratiquement aucune différence, à l'exception de la clé inexistante. Le site la différence de performance varie selon le navigateur et le système d'exploitation que vous utilisez. Mais ce n'est pas vraiment si différent.

Je vous suggère d'utiliser l'interface standard, simplement parce que c'est une façon recommandée de l'utiliser.