The past life of routing

In my opinion, routing is actually telling you where to go after you arrive at a certain location. Signs at crossroads and directions to toilets and elevators in shopping malls are all used in the scenes of life. Going back to the technical side, routing was originally a concept in the back end, accessing an address such as example.com/user, and if the service that example.com corresponds to has already directed /user, then it can reach the method that it should eventually invoke. Front-end routing is similar, when we access a path, if the corresponding path is already registered on the route, then we can show it. But I always have a question here. For example, a path like baidu.com/user, does it display a page through a front-end route, or does it do something else through a back-end route? Next, we first simplify the problem, the front-end route unified understanding as a jump page, back-end route unified understanding as a call interface, first “who is responsible for this work” to make clear.

Trouble # 1 — Who’s doing the work?

Our goal in this section is to clarify whether a route is being processed at the front end or the back end. At present, there are two mainstream front-end routing methods, namely, hash implementation and browser history implementation. Let’s analyze them one by one.

Hash pattern

The principle is that using the # anchor in the URL link, changes following the # will be monitored by the hashChange time and the hash changes will not be picked up by the back end. Therefore, when a hash change causes a page change, it is a pure front-end route change and does not involve back-end routes.

The history mode

The principle isto use the browser provided by the history object to achieve the jump, the main API has the following:

  1. pushState
    1. Use to add a record to history without triggering page updates. That is, we can change the url of the page to whatever form we want through JS, without being perceived by the back end
    2. Call history.pushState(object, title, URL)
      • Object: An object whose contents can be passed to a new page. It’s usually this parameter that makes sense
      • Title: title, usually not used
      • Url: Generally not
  2. replaceState
    1. PushState is used to update the latest record in history to the new value passed in
  3. back
    1. The rollback function of the corresponding browser
  4. forward
    1. The forward function of the corresponding browser
  5. go
    1. History. go(num) jumps to page num relative to the current page
    2. History.go (-1) equals history.back()
    3. History.go (1) equals history.forward()
  6. Popstate event
    1. This event is triggered when the back/go/ Forward methods are called, and we can render the desired page based on the latest history value

To uncover the truth

In hash mode, the content after # is not carried to the back end, so when we select hash mode, it is the front end route that does the page jump for us. “I chose him to be a speaker. He’s contributing to the community.”

But the HISTORY mode URL is very confusing to us. When we click a button from example.com/list, the URL becomes example.com/user and the page becomes /user. From the analysis of phenomena, there is more than one solution to achieve:

  1. Using the history mode of front-end route, js realizes route jump, page update and URL update, in which case the back end will not perceive the change
  2. Use the back-end route to request the backend directly from example.com/user, and the backend returns the corresponding page

Obviously, the second back-end route is not as good as the first front-end route, so how can we confirm which one is used? In network TAB, if the front-end route is implemented, there will be no request for /user. If the back-end route is implemented, there will be a request for /user. At this point, we should be able to identify a url change and who is helping us complete the page update.

Trouble # 2 — Why does history require backend coordination

Let’s dig a little deeper into the history mode, which we described in the previous example, isto pushState or replaceState through js to update the url and update the page, in which case the url is not requested to the back end. However, if you stay at that URL and the user hits the browser’s refresh button, the entire URL is requested to the back end. In this scenario, the backend route needs to be able to recognize the URL, otherwise a 404 condition will occur. For most projects that have adopted a back-end separation, either the backend or Nginx will return HTML for requests beginning with the current domain name, which is also a minor disadvantage of history mode (it requires back-end cooperation). After the HTML is returned, our JS is loaded, and the code related to routing is executed in the JS code. When the current URL is found to be /user, the page corresponding to /user will be rendered, and the display of the page will be finally completed.

Trouble # 3 — Rendering pages by URL, who’s in charge?

This question is to know how to display the page according to the URL when the URL changes. Here we use the React-Router history mode to analyze this process. The router component and Route component are the two most important components for implementing routes in the React-Router.

Router

The Router component is actually a Context Provider component, which is responsible for maintaining and updating the route information, history, location, and other information changes in the Router component. Components that consume the Provider rerender feature, allowing the Route component to sense changes in the URL.

Route

The Route component determines what to render based on whether the path attribute matches the URL. If the path attribute matches the url, render the corresponding component. If the path attribute does not match, render nothing

Trouble # 4 — Asynchronous loading

Some of you may have noticed that in the production environment of a project, we wait until we click on a page to request the corresponding resource. The principle is that on the basis of the packaging tool fragment, the root entry file stores the configuration of different file names corresponding to different routes, which will be obtained when the URL matches. ​

conclusion

Front-end routing brings a great improvement to the experience of using the page, truly allowing the front-end to achieve in addition to persistent data, all by their own control degree. In addition to this part, there is also a need for knowledge and routing intersection. Examples include sharding in Webpack, the more detailed path matching and component rendering mechanisms in React-Router or Vue-Router. Next time, explore the internal implementation of the React – Router.

Refer to the article

Cloud.tencent.com/developer/a…

Juejin. Cn/post / 694347…