Introduction to the

As a front-end developer, there are three common ways of front-end local storage:

  • Cookie
  • sessionStorage
  • localStorage

The purpose of this article is to make clear the difference between these three and their use scenarios. If there are shortcomings in the article, please comment and discuss them. If you are interested, please click “Like” and collect them.

Cookie

Cookie is a browser-provided mechanism that provides JavaScript with the Cookie property of the Document object. It can be controlled by JavaScript, not the nature of JavaScript itself. Cookie is a mechanism proposed by W3C and first developed by Netscape community. Its size is limited to 4KB. Its main purpose is to store login information, such as a “remember password” option when you log into a website, usually by storing a piece of data in a Cookie that identifies the user.

localStorage

HTML5 WebStorage provides API: localStorage

LocalStorage is a new addition to the HTML5 standard, but it’s not a game-changer. Back in IE 6, there was something called userData for local storage, and the more common solution was to use Flash for browser compatibility. Today, localStorage is supported by most browsers.

Permanent storage of data information (5MB recommended, different browsers) the total amount of unlimited, as long as you do not clear. Can be permanently stored locally. Currently, only strings are supported. All other formats are converted to strings. If you want to store other data types, Stringify and Parse can convert them to strings using JSON objects provided by ECMAScript.

sessionStorage

HTML5 WebStorage provides API: sessionStorage

The sessionStorage interface is similar to that of localStorage, but the life cycle of storing data is different from that of localStorage. Those of you who do back-end development know the word Session, which literally translates to “Session.” SessionStorage is a front-end concept, it can only save part of the data in the current session, refresh the page data still exist. But when the page is closed, the data in sessionStorage will be cleared.

The sessionStorage property allows you to access a sessionStorage object. It is similar to localStorage except that data stored in localStorage does not have an expiration date, while data stored in sessionStorage is cleared when the page session ends. The page session remains as long as the browser is open, and the original page session remains when the page is reloaded or restored.

Cookie, sessionStorage, localStorage

features

Cookie

localStorage

sessionStorage

In common

They all have clients (browsers) and they all have the same origin, the same protocol the same domain name the same port, they’re all sets of key-value pairs

The life cycle of data

Generally, it is generated by the server. You can set the expiration time. If no expiration time is set for cookies, the Cookie is stored on the browser side and its life cycle ends when the browser closes. If the expiration time is set, the Cookie is stored on hard disk and disappears when the expiration time expires.

It is stored permanently unless it is removed

This parameter is valid only in the current session. The page will remain the same when you reload or restore the page, and will be cleared after you close the page or browser

Whether it is cross-domain

Can not cross domains, but for the same top-level domain name of the secondary domain can be set by the ‘domain’ method can be cross-domain

Different pages with the same domain name and port in the same browser can share the same localStorage. As long as different sources cannot share localStorage data

SessionStorage information is not shared between different pages

scope

It is shared in all origin Windows

It is shared in all origin Windows

Not shared in different browser Windows, even the same page, as long as in the same window, refresh the page or enter a different page of the same origin, data will always exist, that is to say, as long as the browser is not closed, the data will still exist

Data storage size

A maximum of 4KB and a maximum of 20 cookies can be set for each web site

Generally about 5MB, the total number of unlimited

Communicates with the server

Cookies are passed back and forth between the browser and the server. This is carried each time in HTTP headers, and using cookies to store too much data can cause performance problems

It is saved only in the client (browser) and does not communicate with the server

Stored content type

Only string types can be saved as text

Only string types can be stored. Arrays and objects commonly used in JS cannot be stored directly. You can convert other data types to strings using Stringify and Parse of JSON objects provided by ECMAScript

Ease of use

Requires the programmer to encapsulate, the source Cookie interface is not friendly

The source interface is acceptable and can be repackaged to provide better support for objects and arrays

access

let allCookies = document.cookie; Note that all cookies at the current location are retrieved and an array is returned, separated by a semicolon and a space (;). Doccookies.getitem (name) can be used to obtain a Cookie whose name is known

Use the window object’s window.localstorage to get it

Get it using the window object’s window.sessionStorage

Application scenarios

  • Cookie

    From the security point of view, because each HTTP request will carry Cookie information, so virtually waste bandwidth, so Cookie should be used as little as possible, in addition to Cookie also need to specify the scope, can not be called across the domain, more restrictions. However, cookies are better than storage for identifying user logins. Otherwise, if you can use storage, use storage.

  • localStorage

    LocalStorage is often used for persistent data, such as long-term logins, because it is always active and is always saved when a window or browser is closed.

  • sessionStorage

    SessionStorage is valid only for the current session and will be cleared after closing the page or browser. So it is used to save some temporary data, in case the user refreshes the page and loses some parameters. For example, log in to a sensitive account at a time.

  • Pay attention to

    Not all data fits in cookies, localStorage, and sessionStorage. When using them, you need to be aware of any code that is at risk of XSS injection. As soon as you open the console, you can change their values at will, which means they can do whatever they want with your localStorage if your site has XSS at risk. Therefore, do not use them to store sensitive data in the system, involving money or other important information, it is recommended to use background storage.

Refer to the link

Refer to the article

Refer to the article