Different browsers have limits on the size and number of cookies under the domain name. The capacity of cookies is limited, so the precious space is reserved for interaction with the server.

Many websites will use third-party statistics, ABtest and other JS plug-ins, will also take up your precious cookies, and is very much.

IE8 after the browser began to support localStorage, capacity in M units, give us a lot of imagination, if we use the local localStorage successfully simulate cookie features, want to be able to reduce the burden of cookie a lot.

Based on the following, I wrote a library locally-cookie which has been running stably in the project for several months now.

Github address: github.com/Xing-Chuan/…

Due to the use of the native localStorage API, there are the following limitations

  • Support IE8 +
  • It can be stored in the current domain (primary domain or secondary domain), but not across domains

The principle of

After the set method is used, the localStorage generates prefixed keys to prevent conflicts with other keys. There are two unique keys, LC_keylist and LC_sessionID.

We need to store three types of data:

  • Session data is cleared when the browser is closed
  • Aging data can be stored for hours or days
  • Permanent data, which can store long time

It can achieve appeal 3 points, except that it cannot be shared across secondary domains, which is basically consistent with cookies.

Aging data and permanent data are easy to handle, as long as the timestamp is retained when set and the comparison of values is ok.

In order to store session data, there is a problem to solve first: how to listen for browser closing actions? There is an event onbeforeUnload, we can do something with it, but it is not 100% reliable, maybe you crash and the browser process is killed directly, we expect 100% reliable. Actually, yes, we’ll defer processing the data, and we’ll do it while you’re evaluating it.

We can use the features of the browser to save the same sessionID in localStorage and browser cookie. If the two sides are inconsistent, it means that the browser is closed, and the period of the browser session cookie is consistent, and the compatibility is good.

So my local data structure looks like this

{"expires":1557317410965."value": [1."5".99]}
Copy the code

Expires is the timestamp when data is generated. If it is 0, it is session data and expires when the browser closes the action.

Data storage supports strings, arrays, objects, numbers, and Booleans.

Because we defer processing data, we do not delete expired data when the browser closes. When fetching data, the system checks whether the timestamp expires. If the timestamp expires, the system deletes the data and returns NULL. In the case of session data, check whether the session ids are consistent. If the session ids are inconsistent, initialize the session data, clear all expired session data according to the keyList, and clear keys in the KeyList

The installation

npm i -S locally-cookie
Copy the code

API

Set the set

/ * * * * means the key {String} key, mandatory * value {String | Boolean | Number | Array | Object} value, mandatory * day {Number} 0 session data, Close the browser failure | 1, 2... One day, two days after the permanent failure | 1 theory, optional defaults to 0 * /
localCookie.set('key', value, [day]);
Copy the code

Get the get

/** ** Parameter Description * key {String} Key, mandatory */
localCookie.get('key');
Copy the code

Delete the del

/** ** Parameter Description * key {String} Key, mandatory */
localCookie.del('key');
Copy the code

Whether a set key still has

/** ** Parameter Description * key {String} Key, mandatory */
localCookie.has('key');
Copy the code