Preface:
As a result of the recent mobile development process encountered an operation of the so-called technical difficulties required, for the native app is a breeze, after all, their own app user operation refers to where to play, but H5 how to do? H5 can not be realized. For a love study to conquer these front-end thorny problems, I did not try, I am refusing to put forward the need to say that can not be achieved, and so on.
What is the demand? --demand side requires users to browse through a list page, click on a list to go to the Details page, return the request to record the user just browse the location, rather than re-refresh the page to the top of the page. (PS: If the user finally turned to the first dozens of, hundreds of or even thousands of, do you want users to start again.) Perhaps this time bounce rate is high, this analysis is quite reasonable, unable to refute ... )。
Then the brain hole opened up, then the brain came out of various solutions:
1. Save the scrolling position to the cookie and go to this page to take it. How long will that be destroyed? It seems to be inflexible ... pass
2, the details page through the Ifram or frame to the current page, through the action to close the current pop-up window (then on the completed page re-construction, add the Operation button. So load efficiency and experience. ... Not good anyway)
3, the scroll location of the browse to the server side, load the page, according to the user to take the last browse location, a variety of parameters transferred (similar to the scheme)
4, by H5 local storage way to save the data, need to value (no experience, first study it, it seems pretty reliable)
Now let's look at what local storage is! Introduction:
HTML5 Web Storage, a better local storage method than a cookie.
First let's look at: what is HTML5 Web storage?
Use HTML5 to store the user's browsing data locally.
Earlier, local storage was using cookies. But Web storage needs to be more secure and fast. This data is not saved on the server, but it is used only for user requests for Web site data. It can also store large amounts of data without compromising the performance of the site.
Data exists as a key/value pair, and the Web page's data is only allowed to be used by that page. Localstorage and Sessionstorage
The two objects that the client stores data are: localstorage-data storage with no time limit sessionstorage-data storage for a session ( close window, empty stored data )
Does it fit our needs after knowing the sessionstorage? The data stored in the session, whether you go back or refresh, the data is still in, close the window and then into the page will be emptied data, then fully meet the requirements Ah, see this thing is almost excited to tears ran ...
Then the realization of the idea, ① page scrolling, the scroll position into the session →② again into the page, to the session to remove the last saved browse location →③ scroll to the corresponding location
This guy is so funny to screaming babies ah, open your eyes to see the point.
This is only about SetItem and GetItem, and of course what RemoveItem Delete key, clear clears all key/value operations. SetItem Store Value
Purpose: Store value in the key field
Usage:. SetItem (key, value)
code example:
Sessionstorage.setitem ("Key", "value"); Localstorage.setitem ("Site", "js8.in");
GetItem Get Value
Purpose: Gets the value that the specified key is stored locally
Usage:. GetItem (Key)
code example:
var value = Sessionstorage.getitem ("key"); var site = localstorage.getitem ("site");
Save Scroll position when scrolling
$ (window). Scroll (function () {
if ($ (document). ScrollTop ()!=0) {
Sessionstorage.setitem ("OffsetTop", $ (window). scrolltop ());//Save scroll position
}
});
When onload, remove and scroll to the last saved location
Window.onload = function ()
{
var _offset = Sessionstorage.getitem ("OffsetTop");
$ (document). ScrollTop (OFFSETTOP);
};
can go running effect, certainly unexpected.