1. What is
routing
For a simple example, suppose we have a server that provides a web service with a network address of 10.0.0.1, and the web service provides three pages that can be accessed by users. The page URIs are:
http://10.0.0.1/
http://10.0.0.1/about
http://10.0.0.1/concat
Then the paths are /, /about, /concat respectively.
When the user uses http://10.0.0.1/about to visit the page, the web service will receive the request, and then parse the path /about in the URL. In the web service program, the path corresponds to the corresponding processing Logic, the program will hand over the request to the processing logic corresponding to the path, so that a "route distribution" is completed, and this distribution is completed through "route".
In the past, routing was done in the background, and the specific html page was navigated through the url requested by the user. The front-end routing was done by configuring the js file to take this work to the front end.
Simply put, routing is to display different content or pages according to different URL addresses
2. Front-end
routing
The front-end routing and the back-end routing are technically different, but the principles are the same. Before the emergence of HTML5 history API, front-end routing was implemented through hash, which is compatible with lower version browsers. If we use hash to implement the three pages mentioned in the above example, it needs to carry # in the URI rules.
1http://10.0.0.1/2http://10.0.0.1/#/about3http://10.0.0.1/#/concat
The web service does not parse the hash, which means that the content after # will be automatically ignored by the web service, but JavaScript can be read through window.location.hash. After reading the path and parsing it, it can respond to the logic of different paths deal with.
History is a new API only available in HTML5, which can be used to manipulate the browser's session history. The routing based on history can be the same as the path rules mentioned in the original example.
1http://10.0.0.1/2http://10.0.0.1/about3http://10.0.0.1/concat
How to implement front-end routing will be introduced in a later article.
3. What are the usage scenarios of front-end routing?
Front-end routing is more used in single-page applications, that is, SPA, because single-page applications are basically separated from the front and back ends, so the back end will naturally not provide routing for the front end.
4. Advantages and disadvantages of front-end routing
advantage:
1. From the perspective of performance and user experience, the back-end routing sends a request to the server every time a new page is accessed, and then the server responds to the request. This process will definitely be delayed. The front-end routing only changes the path when visiting a new page. Without network delay, the user experience will be greatly improved.
2. In some occasions, using ajax request, the page can be refreshed, the page has changed but the Url has not changed, the user can not copy to the desired address, using the front-end routing to make a single page page can solve this well problem
Disadvantages:
When using the browser's forward and backward keys, the request will be resent, and the cache is not used properly.
1. Routing is a way to interact with back-end servers, requesting different resources through different paths, and requesting different pages is one of the functions of routing.
if(path='./xxx'){
Do something
}
2. Two ways to implement routing
Before the emergence of these MVC and MVVM frameworks, there was no front-end routing, and the jump between pages was controlled by the back-end. With the rise of front-end and back-end separation, single-page applications (SPA) and the increase in the complexity of WEB projects, coupled with the support of these frameworks, slowly front-end routing has become a reality. The feature of a single page application is that it can update the page view without re-requesting the page by changing the URL.
"Update the view without re-requesting the page" is one of the core principles of front-end routing. There are currently two main ways to implement this function in the browser environment
Use the hash ("#") in the URL
New methods added in HTML5 using History interface
hash
This hash does not refer to the hash table in the data structure, but is similar to https://juejin.im/#123gqwf, by monitoring the a tag, so that the change of the value behind the # number will not send a request or refresh Page, and will trigger the windo.onhashchange event.
pushState
The newly added api in html5, History.pushState()History.replaceState(), these two apis can also change the url without sending a request, and look better than #, the principle is the same, but if the user refreshes the page, the request will also be sent , Returns 404, so back-end cooperation is required. If the user refreshes the page, all unresponsive routes are redirected to the root directory
3. The method and comparison of vue-router to achieve front-end routing
There is a parameter such as mode in vue-router. The optional values of this parameter are "hash", "history", and "abstract"
const router = new VueRouter({
Mode:'history',
Routes: [...]
})
What are the advantages and disadvantages of the "hash" and "history" methods?
First of all, the hash method is used by default in vue-router, because although this method is a bit ugly with a # (the official says so), there is no compatibility problem
However, because the underlying implementation of history calls history.pushState() according to the introduction of MDN, there are browser compatibility issues.
If compatibility issues are not considered, pushState is definitely more powerful than just modifying the hash value, because you can set any homologous URL
PushState can be set exactly the same as the current URL, which will also add the record to the stack, and the new value of the hash setting must be different from the original
Also, even if compatibility issues are not considered, the history mode has another problem, that is, the history mode will modify the URL the same as the URL of the normal request backend.
http://oursite.com/user/id
In this case, if the backend does not configure the corresponding user/id address, it will return 404. The official recommended solution is to add a candidate resource covering all situations on the server side: if the URL does not match any static resources, you should Return to the same index.html page, which is the page your app depends on. After doing this at the same time, the server will no longer return the 404 error page, because the index.html file will be returned for all paths. In order to avoid this situation, cover all routing conditions in the Vue application, and then give a 404 page. (I haven't practiced this kind of scheme, I have a chance to practice it)
So comprehensively, if it is used in some middle and back-end projects, the default method of hash is generally used directly, and the front-end project depends on whether to use history or hash.
