Are there some benefits of using the methods defined on the localStorage object versus accessing the object properties directly? For example, instead of:
var x = localStorage.getItem(key); localStorage.setItem(key, data);
I have been doing this:
var x = localStorage[key]; localStorage[key] = data;
Is there anything wrong with this?
Not really, they are, basically, exactly the same. One uses encapsulation (getter/setter) to better protect the data and for simple usage. You're supposed to use this style (for security).
The other allows for better usage when names(keys) are unknown and for arrays and loops. Use
.length to iterate through your storage items without knowing their actual key names.
I found this to be a great resource : http://diveintohtml5.info/storage.html
This question might provide more insight as well to some: HTML5 localStorage key order
Clearly there has been some confusion about encapsulation. Check out this quick Wikipedia. But seriously, I would hope users of this site know how to google.
Moving on, encapsulation is the idea that you are making little in and out portals for communication with another system. Say you are making an API package for others to use. Say you have an array of information in that API system that gets updated by user input. You could make users of your API directly put that information in the array... using the
array[key] method. OR you could use encapsulation. Take the code that adds it to the array and wrap it in a function (say, a
setWhateverMakesSense() function) that the user of your API calls to add this type of information. Then, in this
set function you can check the data for issues, you can add it to the array in the correct way, in case you need it
shifted onto the array in a certain way...etc. you control how the input from the user gets into the actual program. So, by itself it does not add security, but allows for security to be written by you, the author of the API. This also allows for better versioning/updating as users of your API will not have to rewrite code if you decide to make internal changes. But this is inherent to good OOP anyhow.
(Therefore, in response to Natix's comment below...)
localStorage object, they have already written this API, they are the author, and we are its users. If the authors decide to change how
localStorage works, then it will be less likely to have to rewrite your code if the encapsulation methods were used. But we all know its highly unlikely that this level of change will ever happen, at least not any time soon. And since the authors didn't have any inherent different safety checks to make here, then, currently, both these ways of using
localStorage are essentially the same. It's kind of like a shim. However, we can easily overwrite/replace the existing encapsulation around
I think they are exactly the same, the only thing the documenation states is:
If using the full shim, however, it states that:
The use of methods localStorage.yourKey = yourValue; and delete localStorage.yourKey; to set or delete a key is not a secure way with this code.
and the limited shim:
The use of method localStorage.yourKey in order to get, set or delete a key is not permitted with this code.
One of the biggest benefits I see is that I don't have to check if a value is undefined or not before I JSON.parse() it, since getItem() returns NULL as opposed to undefined.
As long as you don't use the "dot notation" like window.localStorage.key you are probably OK, as it is not available in Windows Phone 7. I haven't tested with brackets (your second example). Personally I always use the set and get functions (your first example).
©2020 All rights reserved.