“This is the fourth day of my participation in the Gwen Challenge in November. Check out the details: The Last Gwen Challenge in 2021.”

1. The beginning of the story: Cookie

The job of a Cookie is not to store it locally, but to “maintain state.”

In the early days of Web development, one of the most urgent issues was state management: HTTP was a stateless protocol. The server received a request from a client, returned a response, and the story ended there. The server did not record any information about the client. So how do you let the server know “I’m me” the next time you make a request?

In this context, cookies came into being.

A Cookie is basically a small text file stored in a browser, attached to an HTTP request, that flies back and forth between the browser and the server. It can carry user information, and when the server checks the Cookie, it can get the status of the client.

1.1 Performance Disadvantages of Cookies

  • A Cookie is not big enough
  • Excessive cookies can lead to a huge performance waste
    • Cookies follow the domain name.
    • All requests under the same domain name carry cookies.

2. Lean in: Web Storage

Web Storage is a data Storage mechanism provided by HTML5 specifically for browser Storage. It is divided into Local Storage and Session Storage. These two sets of concepts are very similar, so we might as well understand the differences between them first, and then study their commonalities.

2.1 Differences between Local Storage and Session Storage

  • The difference lies in the lifecycle and scope.

Life cycle:

Local Storage is persistent Local Storage. Data stored in it will never expire. The only way to make it disappear is to manually delete it.

Session Storage is temporary local Storage. It is session-level Storage. When the Session ends (the page is closed), the Storage content is released.

Scope:

Local Storage, Session Storage, and Cookie all follow the same-origin policy.

However, the special point of Session Storage is that even if two pages under the same domain name are not opened in the same browser window, their Session Storage content cannot be shared.

2.2 Features of Web Storage

Large Storage capacity: Web Storage The Storage capacity ranges from 5 to 10 MBIT/s depending on the browser.

It is only on the browser side and does not communicate with the server.

2.3 Application Scenarios

2.3.1 the Local Storage

  • Local Storage has no special restrictions on Storage. In theory, all data Storage tasks that cookies cannot handle and can be accessed by simple key-value pairs can be entrusted to Local Storage.

  • Considering that one of the characteristics of Local Storage is persistence, sometimes we prefer to use it to store some stable resources. For example, image-rich e-commerce sites will use it to store Base64 image strings:

  • Some websites also use it to store static resources such as CSS and JS that are not updated frequently.

2.3.2 Session Storage

Session Storage is more suitable for storing life-cycle and session-level information that it synchronizes. This information only applies to the current session and needs to be updated or released when you start a new session.

For example, the Session Storage of Weibo is mainly used to store the browsing footprint of this Session:

The Last URL corresponds to the Last URL you visited, which is immediate. It updates when you switch urls, and there’s really no point in keeping it when you close the page, just release it. Such data is best handled by Session Storage.

Web Storage is an extension of cookies, which can only be used to store a small amount of simple data. When it comes to large, complex data, Web Storage can’t help. IndexedDB! IndexedDB! IndexedDB!

3. Final form: IndexedDB

IndexedDB is a non-relational database that runs on a browser.

Since it is a database, it is not 5M, 10M, such a small level of play. Theoretically, IndexedDB has no storage upper limit (generally no less than 250MB). It can store binary data as well as strings.

3.2 features

  1. IndexedDB is a transactional database system, indexed table system
  2. Operations performed with IndexedDB are done asynchronously so as not to block the application
  3. Data cannot be accessed across domains

3.3 process

  1. Open a database.
  2. Create an object library in the database.
  3. Start a transaction and make a request to perform some database operation, such as adding or retrieving data.
  4. Wait for the operation to complete by listening for the correct DOM event.
  5. Do something with the result (which can be found on the request object).

3.4 interface

Get with indexedDB

/ / get with indexedDB
export const indexedDB = (win: any = window) :IDBFactory= >
  win.indexedDB || win.webkitIndexedDB || win.mozIndexedDB || win.msIndexedDB;
export const IDBTransaction = (win: any = window) = >
  win.IDBTransaction ||
  win.webkitIDBTransaction ||
  win.msIDBTransaction || { READ_WRITE: 'readwrite' };
export const IDBKeyRange = (win: any = window) = >
  win.IDBKeyRange || win.webkitIDBKeyRange || win.msIDBKeyRange;
/ / testing
export const isSupportIndexedDB = () = > {
  const db = indexedDB();
  if (db) {
    return true;
  } else {
    console.error(Your browser doesn't support Indexed DB);
    return false; }};Copy the code

Open the database

const request = (name,version)=>indexedDB().open(name,version)
Copy the code

3.5 compatibility

3.6 Application Scenarios of IndexedDB

With IndexedDB, we can create multiple databases, with multiple tables in one database and multiple data in one table — enough to hold complex structured data.

IndexedDB can be seen as an upgrade to LocalStorage, and when the complexity and size of the data becomes too large for LocalStorage to handle, IndexedDB can certainly be used to help.