Routing? Front-end routing and back-end routing? How can front-end routing be implemented?

1. What is routing? Routing is to display different pages or content based on different URLS.

2. What is front-end routing and what is back-end routing, and what are the similarities and differences between them? Front-end routing refers to: different URL addresses correspond to different content or pages. This task is accomplished by the front-end, namely front-end routing, which will not refresh the page. With the popularity of SPA single page application and the separation of front and back ends, the current projects are basically front-end routing. Advantages: Complete separation of front and back ends, no page refresh, better user experience, better page durability, such as music website, when you play a song, switch the page, the playback will not be interrupted. These are all spa benefits;

Back-end routing: When switching between urS in the address bar, a request is sent to the server. The server responds to the request by stitching together the HTML file on the server and returning it to the page for display. Advantages: reduce the front-end pressure, HTML is spliced by the back end; Disadvantages: Dependent on the network, slow network speed, poor user experience, when the project is relatively large, the server side pressure is large, cannot enter the specified URL in the address bar to access the corresponding module, the front end is not separated.

3. Since front-end routing is a common practice, how to achieve front-end routing? There are two implementation modes of front-end routing: (1) Hash mode: A hash is the content after the # in a URL. The hash is included in the URL but not included in the HTTP request. It is used to direct browser actions and is not secure on the server side. So for the back end, 404 will not appear even if there is not full routing coverage). So you can use Onhashchange to listen for route changes to change the content of the page (to make ajax requests).

Html5 has two new apis, history.pushState() and history.replacestate (), which both manipulate the browser’s history stack without causing a page refresh. But in this case there is no way to listen for URL changes as useful as onHashchange, so you need to control from three angles.

History.pushstate () and history.replacestate () both require three arguments: history.pushState(data, null, ‘#/page=1’); PushState accepts three arguments. The first argument is obj, which represents the state property of the browser. Popstate can be used with this property. The second argument is the value of document.title, which is usually set to null; The third argument, string, is used to change the current URL; First of all, the front-end route change can be caused by several actions, so we need to handle each of them differently: First, we need to maintain a mapping between a URL and its corresponding callback function (this callback function refers to the things to do after jumping to a URL, such as content replacement on the page, Ajax request, etc.)

  • When a TAB is clicked to jump to the page, add an onClick event to a TAB. The event callback will prevent the default jump behavior of a TAB, and obtain the URL via event.target.href.
  • When history.pushState() and history.replacEstate () are called directly in the script (which does not trigger onPopState), they are also executed through the url’s callback to the mapping;
  • Click the browser’s forward and back buttons. Another event, onPopState, is triggered when the browser history is activated. This event callback retrieves the current URL and executes the callback based on the mapping.
PushState accepts three arguments. The first argument is obj, which represents the state property of the browser. Popstate can be used with this property. The second argument is the value of document.title, which is normally set to 'null'; The third argument, string, is used to change the current URL;Copy the code

First of all, the front-end route change can be caused by several actions, so we need to handle each of them differently: First, we need to maintain a mapping between a URL and its corresponding callback function (this callback function refers to the things to do after jumping to a URL, such as content replacement on the page, Ajax request, etc.)

  • When a TAB is clicked to jump to the page, add an onClick event to a TAB. The event callback will prevent the default jump behavior of a TAB, and obtain the URL via event.target.href.
  • When history.pushState() and history.replacEstate () are called directly in the script (which does not trigger onPopState), they are also executed through the url’s callback to the mapping;
  • Click the browser’s forward and back buttons. Another event, onPopState, is triggered when the browser history is activated. This event callback retrieves the current URL and executes the callback based on the mapping.
route1:callback1, route2:callback2, route3:callback3 }; Window. onpopState = function(event){var state = event.state; routeMap[state.route].call(this); }Copy the code
function clickHandler (event){
        var route = event.target.href;
        history.pushState({route:route},null,route);
        routeMap[route].call(this);
        return false;
    }
Copy the code

Note that because the URL in history mode is the same as the url from the back end, the server needs to support (to ensure full coverage of the route) that all URL requests point to the same HTML, otherwise the refresh will report 404. This was the case with the VUE project, when the page was refreshed it was 404 because the back end didn’t have full routing coverage.

Hash mode is relatively simple, but the url of the address bar will have #, which is not beautiful; In history mode, the address bar will look like a normal website with “/” no “#”, but requires the server side to do the full coverage configuration of the route.