Write it first: Usually there are two ways to implement front-end routing in SPA:
Let's introduce how these two methods are implemented in detail
1.history
Basic introduction
Objects contain the history of the browser, and the prefix of window can be used when writing objects. History is a mainstream method that implements SPA front-end routing, and it has several original methods:
- () - Same as clicking the back button in the browser
- () - Same as clicking the button forward in the browser
- (n) - Accept an integer as a parameter and move to the page specified by the integer. For example, go(1) is equivalent to forward(), go(-1) is equivalent to back(), go(0) is equivalent to refresh the current page
- If the moving position exceeds the boundary of the access history, the above three methods do not report an error, but fail silently
In HTML5, the history object proposes pushState() method and replaceState() method. These two methods can be used to add data to the history stack, just as the url has changed (in the past, only the url changes the history stack will change), so that it can simulate browsing history and advance and backwards well. The current front-end routing is also implemented based on this principle.
The pushState(stateObj, title, url) method writes data into the history stack. The first parameter is the data object to be written (not greater than 640kB), the second parameter is the title of the page, and the third parameter is the url (relative path).
- stateObj: A state object related to the specified URL. When the popstate event is triggered, the object will be passed into the callback function. If this object is not needed, you can fill in null here.
- title: The title of the new page, but all browsers currently ignore this value, so you can fill in null here.
- url: The new URL must be in the same domain as the current page. The browser's address bar will display this URL.
There are several notable things about pushState:
PushState method will not trigger page refresh, but will only cause history object to change, and the address bar will react. The browser will refresh only when forward, backward, and other events such as backward (back() and forward(), etc.) are triggered.
The url here is restricted by the same-origin policy, which prevents malicious scripts from imitating other websites. URLs are used to deceive users, so an error will be reported when violating the same-origin policy.
The difference between replaceState(stateObj, title, url) and pushState is that it is not written but replaces and modifys the current record in the browsing history. The rest is exactly the same as pushState
event
Definition: Whenever the browsing history (i.e. history object) of the same document changes, the popstate event will be triggered.
Note: Just calling the pushState method or replaceState method will not trigger this event. It will only be triggered when the user clicks the browser back button and forward button, or calls back, forward, and go methods using JavaScript. In addition, this event is only for the same document. If the browsing history switches, causing different documents to be loaded, the event will not be triggered.
Usage: When using it, you can specify a callback function for the popstate event. The parameter of this callback function is an event event object, and its state attribute points to the state object provided by the pushState and replaceState methods (i.e. the first parameter of these two methods).
Implement spa front-end routing code
<a class="api a"></a>
<a class="api b"></a>
// Register a route ('.api').forEach(item => {
('click', e => {
();
let link = ;
if (!!( && )) {
// Support History API ({name: 'api'}, link, link);
} else {
// Not supported, some Polyfill libraries can be used to implement it }
}, false)
});
// Listen to routes ('popstate', e => {
({
location: ,
state:
})
}, false)
What is printed in the popstate listening function is the first parameter passed in (), which is {name: 'api'}
2. Hash
Basic introduction
There can be a hash in the urlhttp://localhost:9000/#/
There is an event in the window object that is onhashchange, and the following situations will trigger this event:
- Change the browser address directly, add or change #hash at the end;
- by changing the value of or;
- By triggering clicking on links with anchor points;
- The browser's forward and backward may cause a hash change, provided that the hash values in the two web page addresses are different.
Implement spa front-end routing code
// Register a route ('.api').forEach(item => {
('click', e => {
();
let link = ;
= link;
}, false)
});
// Listen to routes ('hashchange', e => {
({
location: ,
hash:
})
}, false)
The hash mode and history mode, both modes are implemented through the browser interface. In addition, vue-router also prepares an abstract mode for non-browser environments. The principle is to simulate the function of the browser history stack using an array stack. Of course, the above are just some core logic, and there is a lot of auxiliary logic in the source code to ensure the robustness of the system, which is also worth learning.
3. Comparison of the two modes
- The new URL set by pushState can be any URL with the same origin as the current URL; and hash can only modify the part after #, so you can only set the URL with the same document as the current URL.
- The new URL set by pushState can be exactly the same as the current URL, which will also add the record to the stack; and the new value set by hash must be different from the original before the record will be added to the stack.
- pushState can add any type of data to the record through stateObject; while hash can only add short strings
- pushState can additionally set the title attribute for subsequent use
4. A problem with history mode
We know that for single-page applications, the ideal usage scenario is to load only when entering the application. The subsequent network operations are completed through Ajax, and the page will not be re-requested according to the URL. However, special situations are inevitable, such as the user directly enters and presses in the address bar, and the browser restarts and reloads the application.
The hash pattern only changes the content of the hash part, and the hash part will not be included in the HTTP request:
/#/user/id // If re-requested, it will only be sent/
Therefore, there will be no problem in the hash mode when you encounter the request page based on the URL.
The history mode will modify the URL just like the URL on the normal requested backend
/user/id
In this case, a request is sent to the backend again. If the backend does not configure the routing processing for the corresponding /user/id, a 404 error will be returned.
The officially recommended solution is to add a candidate resource to the server that covers all situations: if the URL does not match any static resources, it should return the same page, which is the page your app depends on. After doing this at the same time, the server no longer returns the 404 error page, because the file will be returned for all paths. To avoid this, cover all routing situations in the Vue application and then give a 404 page. Or, if it is used as the background, you can use the server route to match the URL, and return 404 when no route is matched, thus achieving fallback.
References:
1. Browser History API:/zh-CN/docs/Web/API/History_API
2. Solution to solve the History mode access 404:/zh/guide/essentials/#%E5%90%8E%E7%AB%AF%E9%85%8D%E7%BD%AE%E4%BE%8B%E5%AD%90
The above is all the content of this article. I hope it will be helpful to everyone's study and I hope everyone will support me more.