Client-side Virtual Storage with jQuery

In some cases, it is absolutely pointless and unreasonable to load both the client part of the web application and the server part. In order not to walk around for a long time, I will give an example from life. From the developer I got one online store, in which the work with the basket occurred as follows. When clicking on the add product button in the cookie, the product ID and its quantity were saved. Accordingly, when visiting different pages, the user is shown what is in the basket, in what quantity, how much it costs and other data, the server application had to perform the following functions:

1. getting a list of product IDs from a cookie;
2. a request to the database from which the product name, its value and other necessary data were returned;
3. using a template engine (Smarty) to generate a block of the basket along with the generation of the rest of the content.

Everything seems to be nothing. I think many have come across such schemes more than once. But I was faced with the task of optimizing the application, and I decided to remove, among other things, the extra load from the server by eliminating both queries in the database and generating a basket block. I would like to store all data on selected products on the client side. Moreover, ideally, I wanted to store not only the array of selected products, but also the ready-made HTML-code of the cart block, in addition, a table with goods for the checkout page. But how to do that?

You can wait a long time for cross-browser JavaScript support with client storage. And to use a cookie for this task is impractical, at least because the length of the string in the cookie is very limited. I offer the following solution in the form of a jQuery plugin and a small addition to the server side.

Javascript

')

;(function($){ var self={ config: { //   ,        callback: function(){}, //    path: 'storage.php' }, current: { // ? first: true }, //   storage: {}, init: function(objects,config){ if(!self.current.first)return; self.current.first=false; //.  $.extend(self.config,config); //.  self.storage=objects; //.  self.get(); $(window).unload(self.set); $('iframe').unload(self.set); }, //  ext: function(objects){ for(var k in objects){ if(typeof(self.storage[k])=='undefined'){ self.storage[k]={}; }; // if(typeof(objects[k])=='object'){ $.extend(true,self.storage[k],objects[k]); } else { self.storage[k]=objects[k]; }; }; }, //    get: function(){ $.getJSON(self.config.path,function(data){ self.ext(data); self.config.callback(); }); }, //   set: function(){ $.ajax({ type: 'POST', url: self.config.path, data: { storage: JSON.stringify(self.storage) } }); } }; $.extend({ storage: self.init, storageUpdate: self.set }); })(jQuery); 

PHP: storage.php

 <? session_start(); if(isset($_POST['storage'])){ $_SESSION['storage']=$_POST['storage']; } elseif(isset($_SESSION['storage'])){ echo $_SESSION['storage']; } ?> 

Thus, we have a virtual storage of any data on the client side with indirect use of the server. How can this be applied in practice?

 var a={i:0}; $(function(){ $.storage({storageA:a},{ callback: function(){ a.i++; alert('    '+a.i+'- .'); } }); }); 

That is, for the application developer, the data storage scheme is absolutely transparent, and he should not worry about how and how to store the data. In this case, all the data of object a before going to another page will be stored in our repository. And immediately after opening another page, the data will be entered into the object a .

PS Many can exclaim, they say, why such complexity, if you can optimize the server part of the application, store the data immediately in the session and give the same object to the client immediately when generating the page (there are lots of options). I have an answer. Let's imagine that we have taken the path of optimizing the application, where almost all dynamic pages are stored in a temporary server cache in a static HTML form. By the way, if it is necessary to store more important data in this way, this scheme can be “salted” with hash protection using a cookie.