Common front-end data storage solutions mainly include:Cookie、Web Storage、IndexedDB、WebSQL、local Storage、session Storageetc., for example:
| characteristic | cookie | localStorage | sessionStorage | indexedDB | | Data lifecycle | Generally generated by the server, the expiration time can be set; Components such as front-end adoption and js-cookie can also be generated | Unless cleaned up, it is always there; When the browser is closed, it is also saved locally, but cross-browser is not supported | Cleaning and refreshing the page will still exist when the page is closed, and cross-page interaction is not supported | Unless cleaned up, it has always existed | | Data store size | 4K | 5M | 5M | No size limit | | Communicate with the server | It is carried in the requested header every time, which has an impact on the performance of the request; At the same time, because it is included in the request, it is also prone to security issues | Not participating | Not participating | Not participating | | peculiarity | String key-value pairs store data locally | String key-value pairs store data locally | String key-value pairs store data locally | IndexedDB is a non-relational database (operations via SQL statements are not supported). It can store large amounts of data, provide interfaces to query, and build indexes, which other storage solutions cannot provide. |
IndexedDB
This article mainly describes the use of IndexedDB for front-end storage, and is introduced as follows:
IndexedDB is an underlying API for storing large amounts of structured data (also file/binary large objects (blobs)) on the client side. The API uses indexes to enable high-performance searches of data. While Web Storage is useful for storing smaller amounts of data, it is not as good as storing larger amounts of structured data. IndexedDB provides a solution for this scenario. This page is the main guide page for MDN IndexedDB - here, we provide a full API reference and usage guide, browser support details, and links to some explanations of key concepts. IndexedDB has the following features:
(1) Key-value pair storage. IndexedDB uses an object store to store data. All types of data can be deposited directly, including JavaScript objects. In the object repository, data is stored in the form of "key-value pairs", and each data record has a corresponding primary key, which is unique and cannot be duplicated, otherwise an error will be thrown.
(2) Asynchronous. IndexedDB does not lock the browser and the user can still perform other operations, in contrast to LocalStorage, which operates synchronously. Asynchronous design is to prevent large amounts of data from being read and written, slowing down the performance of web pages.
(3) Support affairs. IndexedDB supports transactions, which means that if one of the operation steps fails, the entire transaction will be canceled, and the database will be rolled back to the state before the transaction occurred, and there is no case of rewriting only part of the data.
(4) Homology restriction. IndexedDB is subject to the same origin limit, and each database corresponds to the domain name that created it. Web pages can only access databases under their own domain names, not cross-domain databases.
(5) Large storage space. IndexedDB has a much larger storage space than LocalStorage, generally no less than 250MB, and there is no upper limit.
(6) Support binary storage. IndexedDB can store not only strings but also binary data (ArrayBuffer objects and Blob objects).
If it is difficult to get started directly with IndexedDB and you need to encapsulate it yourself, you can use some packaged packages, as follows:
- localForage: A simple Polyfill that provides a simple value syntax for client-side data stores. It uses IndexedDB in the background and falls back to WebSQL or localStorage in browsers that don't support IndexedDB.
- Dexie.js: IndexedDB's wrappers allow for faster code development through simple syntax.
- ZangoDB: An IndexedDB interface similar to MongoDB, supporting most of MongoDB's familiar filtering, projection, sorting, updating, and aggregation functions.
- JsStore: An IndexedDB wrapper with SQL syntax.
- MiniMongo: MongoDB in client memory supported by localstorage, server synchronization via http. MeteorJS uses MiniMongo.
- PouchDB: A client that implements CouchDB in the browser using IndexedDB.
- idb: A tiny (〜1.15k) library with most of the API similar to IndexedDB, but with some minor improvements that greatly improve the usability of the database.
- idb-keyval: Super simple and small (~600B) promise-based key-value pair storage implemented with IndexedDB.
- sifrr-storage: A very small (~2kB) promise-based client-side key-value database. Implemented based on IndexedDB, localStorage, WebSQL, and Cookies. It can automatically select the supported databases mentioned above and use them in order of priority.
- lovefield: Lovefield is a relational database for web apps, written in JavaScript, can run in different browser environments, and provides a SQL-like API that is fast, secure, and easy to use.
localForage
localForage is a fast and simple JavaScript repository. localForage improves the offline experience of web applications by using asynchronous storage (IndexedDB or WebSQL) and a simple API similar to localStorage. localForage uses localStorage in browsers that don't have IndexedDB or WebSQL support.
GitHub address:The hyperlink login is visible. Chinese Tutorial:The hyperlink login is visible.
localForage provides two different js files, the differences are as follows:
localforage.js: a Promise library containing the lie implementation (The hyperlink login is visible.), the file is relatively large, and the promise syntax can be used in older browsers.
localforage.nopromises.js: There is no implementation of Promise, only new versions of browsers are supported.
Test code:
(End)
|