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?
getItem() allows you to access the data stored in the browser's localStorage object.
setItem() : This method is used to add a key and a value to localStorage. getItem() : This method is used to get an item from localStorage using the key.
sessionStorage is similar to localStorage ; the difference is that while data in localStorage doesn't expire, data in sessionStorage is cleared when the page session ends. Whenever a document is loaded in a particular tab in the browser, a unique page session gets created and assigned to that particular tab.
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 .key()
and .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 setArray()
or 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 push
ed or shift
ed 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...)
In the case here of javascript and the 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 localStorage
to make our own security checks. Because JavaScript is just that awesome.
PT
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With