[History of a single-page application] detailed History brings a nightmare to a single-page application

Preface

In our daily web browsing, we like to do one thing: Click the browser to move forward and backward.
After the emergence of Ajax technology, sometimes moving forward and backward will cause problems for developers, and even some developers try to kill History
With the development of Html5, mobile terminals are booming, and single-page applications are emerging, so History processing has to be put on the agenda!
You know, this has always been a big pitfall that people don't want to touch, but single-page applications have to solve it.

First, the processing logic of History seems simple, but it is actually responsible. If you don't pay attention to it, problems will occur. Here we will discuss the handling rules of History on a single page.

Basic knowledge

The historical object of History in javascript contains the URL Information that the user has browsed. This is our legendary historical record.
We usually use the forward/back method and a length interface, or the specific layer of go

Later, the browser vendor found that the History object was indeed too tight, and released two key interfaces, pushState and replaceState, to operate the History object.

So one of our key points today is the pushState and replaceState. These two students can press the object to History and will be triggered when the browser moves forward and backward.

PushState

PushState writes an object to History. The result is
① History length + 1
② Url change
③ This index History corresponds to a State object.

At this time, if you click back from the browser, the popstate event will be triggered to read the stored data object. Here is a simple example.

Go to the first page to go to the second page to go to the third pageView Code

When we click the first page, we input data to History and write the State object (currently msg) to it. Then we will trigger the popstate event when we exit the browser.
At this time, our URL has changed, and we can perform the operation when the event point is triggered. Here, the Operation changes the msg information.
So here we get the result:
① PushState will change History
② During each use, we will add custom data to the State of the index.
③ Every time the History changes (forward, back, And go), The popstate is triggered and the State of the corresponding index is obtained.
④ Each time we restore the current view based on the State information, the user will feel the same as the browser's move forward after clicking back.

Now we have a problem. It turns out that we can't do anything in History. Now the State can be stored in capacity. Because the State can store anything, many users will start to mess up, is there a limit on its capacity at this time?

Go to the first page to go to the second page to go to the third pageView Code

Http://sandbox.runjs.cn/show/69oovy4b

A large string is saved here, and a click is made. It seems that the problem is not big, so I don't pay attention to it. The basic knowledge is also here.
PS: we can obtain the current status value based on history. state.

History and single-page pitfalls

In a regular webpage, the first time you enter a website, the History length is 1. If no special processing is performed, the State is null.
The length of the link operation of this label will be 1

In a single page, the same is true for the basic idea. The difference is that we change pages one by one, and each page card on one page
Our current page Jump is
A-> B-> C-> D
To put it bluntly, this is only the display and hiding of four dom objects on the page.
Therefore, all our rules are expected to be consistent with the History logic, so annoying rollback problems can be returned to the browser, for example:
A-B-C
Now we want to return from C to B. There are two possible actions at this time. Different actions may lead to different results.
One is forward B, and the other is back B.
Forward will form the A-B-C-B's History queue results
Back is still the A-B-C, and is currently in B state, the browser forward available

This is actually consistent with the browser. For example, after A enters B, the link label on page B is linked to.
Then, B returns the result of A, which is similar to the above.

The disgusting things are often related to not playing cards according to the routine. For example, once you enter a website, you can click the browser to exit. The same thing will happen on the Mobile End.

For example, if I directly link the URL to the List page, then clicking the browser does not have a back operation, but our traditional single-page application header will have a back-up button.
At this time, it will be 2B in a moment, because I click the back button will certainly be able to return to the index page, so the framework and browser's History will be messy

This rollback is full of xuanjicang. It is the processing logic when History is smaller than 1. Here we will not insert a new value to History sometimes, so

The browser seems to be B at this time, and the framework's route is B-> A, so we click A's search to go to the List page again (B). At this time
Framework: B-> A-> B
Browser: B-> B
At this time, we clicked the browser rollback elegantly. Page B found that its History was greater than 1, so we executed the browser rollback operation and the results were all messy.

Of course, in general, we will not do the same as above. We will insert data to History during B-> A to keep them consistent.
Framework: B-> A-> B
Browser: B-> A-> B

The situation is often not so optimistic. More often, the following scenarios

After the order is completed on the order filling page, we click OK and jump to the order completion page. At this time, we suddenly found a rollback button on the order completion page, the behavior at this time is not our final decision. The possible scenarios are as follows:
① Return to the order filling page (this action is the least likely to have expired)
② Return to the product search page
③ Return to the homepage
④ Return to the Order List page

The above is the demand for business logic, but we click back in the browser to find Nima again (back to the order page)
As a result, the business logic and browser logic are broken again. This time it is not so bad, because it involves another fact!
The order completion page is shared and has at least three portals.
① Order filling page
② User order list
③ Copy a url to open a new page (this scenario is rare)

Business rollback is not simply a browser rollback, and the order list and order completion may not be a channel (there are ③ problems)

This situation restricts the business needs. Even if the code logic capabilities of business colleagues are directly related, there will be a lot of logic on a simple order completion page.
So the actual situation is that History processing is still a world challenge.

So the reality is that we will not perform special operations on History.

Another more interesting situation is:
On page A, I enter page B, and then on page B, I use window very 2B. location refers to page A, and A's back button uses native History. back, it will be an endless loop.
This scenario has actually happened. At that time, we had a payment page to go to the gift card page for operations (cross-Channel). Then, after the gift card is successful, we directly use window. loacation to indicate
Payment page. At this time, the payment page is clicked back and the gift card page is returned, while the gift card page is very 2B or window. location, so everyone understands the result.

The probability of the above scenario should be said to be low. For example, another more disgusting scenario occurs when hybrid is embedded.
When the native public component is called on the web channel page, the native page is displayed, and the web channel page is returned (the History in webview is blank at this time)
When we click the back of the page card, it is very likely to operate window. location. However, if the Back-to-hop page is unfortunately Historyback
Then he will return ......

Okay. Today I am chatting about History. If you have any solutions to handle History, please do not give me any further advice.