Introduction
This specification allows web application to store the data in structured and persistence manner. This storage mechanism is similar to HTTP session cookies. But the web storage resolves the problems that are with cookies implementation like
- Storage limit: Cookies can store 4KB data only
- Performance issues: With every request cookies are transmitted to server
- Accessibility issues: Per domain there are numbers of cookies created by different browsers
Session storage: Web application can store data into session store which can be accessible by same application within any window opened in same/another browser session/instance. The data stored into this storage is cleared off when a browser window is closed.
Local storage: This storage type allows application to store data that can be persisted across multiple browser session or reboots. It can act as a permanent repository to store data that is required to be remembered by your computer unless user tries to clear the data using browser’s data clean up wizard.
While we think of power to store in better way the good questions to ask are what about security of data and what about storage limit/constraint. Though the data is stored per domain and will be restricted by browser to have access to that domain only there are going to be potential risks from cross-directory and DNS spoofing attacks. On the space limit, W3C specifies the ideal space limit to be 5MB but it can be up to the browser vendor to decide. In order to not navigate away from the theme to describe the API let’s move on to the user cases.
Use case
There could be many scenarios where one can think of using web storage to achieve some purpose, like storing data for sticky notes, remembering how many times user visited a page, bookmarking page number in a flip book application where user has left last time, language preference user selected during signing into an application and many more.
If we use cookies to remember how many items user has added it to a shopping cart for an eCommerce transaction then we might have cross-window transaction issues. If a user is buying movie ticket in two different windows, using the same site then as the user clicked from page to page in both windows, the ticket currently being purchased would "leak" from one window to the other, potentially causing the user to buy two tickets for the same movie without really handling the scenario. Session storage for this situation would solve this problem.
Another good example to use local storage is to cache the metadata information for a diagram creation tool. The tool can allow user to draw a diagram and add multiple components which user might just leave in the middle without actually pushing draft to server. When this happens tool might store information about components, their position, colors, settings, etc into a local storage so when user resumes the tool can re-apply design panel with same state of diagram that user had created earlier.
Example
No comments:
Post a Comment