Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>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).</p> <p>The other allows for better usage when names(keys) are unknown and for arrays and loops. Use <code>.key()</code> and <code>.length</code> to iterate through your storage items without knowing their actual key names.</p> <p>I found this to be a great resource : <a href="http://diveintohtml5.info/storage.html" rel="nofollow noreferrer">http://diveintohtml5.info/storage.html</a></p> <p>This question might provide more insight as well to some: <a href="https://stackoverflow.com/questions/8340845/html5-localstorage-key-order">HTML5 localStorage key order</a></p> <h2>Addendum:</h2> <p>Clearly there has been some confusion about encapsulation. Check out this quick <a href="https://en.wikipedia.org/wiki/Encapsulation_(computer_programming)" rel="nofollow noreferrer">Wikipedia</a>. But seriously, I would hope users of this site know how to google.</p> <p>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 <a href="https://en.wikipedia.org/wiki/Application_programming_interface" rel="nofollow noreferrer">API</a> 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 <code>array[key]</code> method. OR you could use encapsulation. Take the code that adds it to the array and wrap it in a function (say, a <code>setArray()</code> or <code>setWhateverMakesSense()</code> function) that the user of your API calls to add this type of information. Then, in this <code>set</code> function you can check the data for issues, you can add it to the array in the correct way, in case you need it <code>push</code>ed or <code>shift</code>ed onto the array in a certain way...etc. <strong><em>you</em></strong> 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 <a href="https://en.wikipedia.org/wiki/Object-oriented_programming" rel="nofollow noreferrer">OOP</a> anyhow.</p> <p>In the case here of javascript and the <code>localStorage</code> object, they have already written this API, they are the author, and we are its users. If the authors decide to change how <code>localStorage</code> 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 <em>different</em> safety checks to make here, then, currently, both these ways of using <code>localStorage</code> are essentially the same. It's kind of like a shim. However, we can easily make our own encapsulation to overwrite/replace the existing encapsulation around <code>localStorage</code> to make our own security checks.</p> <p>PT</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload