preface

During the interview, I had prepared the two ways of realizing routes and their differences in the front-end framework, but I didn’t make special efforts to understand them thoroughly at that time, so I searched others’ summaries on the Internet and temporarily held them. But it turns out, come out to mix, always, in the interview later met again, and ask the more in-depth, only by rote learning knowledge is always forget quickly, what others summary ultimately others online, given that people summarize the contents of the online a bit chaotic, decided to oneself in the summary record, to deepen our impression.

What is front-end routing

The concept of routing comes from the server side. In SPA (single-page application), routing describes the mapping relationship between URL and function. That is, when you enter a URL in the browser, the corresponding controller will parse the submitted request, and then match the route to find the corresponding module and function for execution.

The two core implementation issues are how to detect route changes and how to change the URL without refreshing the page. There are usually two implementation modes, one is Hash mode and the other is History mode.

Early implementations of front-end routing were based onlocation.hashTo achieve,location.hashThe value of # is the content after # in the URL and the idea is to listen for the content after # to make Ajax requests for local updates without refreshing the entire page.
usehashchangeEvent to listen for changes in the URLhashchangeEvent: the browser moves forward or backward and changes the URL,<a>The tag changes the URL, window.location changes the URL.

Compatible with older browsers, Angular1.x and Vue use hash routing by default
Only the content before the # symbol is included in the request and sent to the back end, meaning that the back end does not return a 404 error even if it does not have full routing coverage
Changes in the hash value add a record to the browser’s access history, so you can use the browser’s back and forward buttons to control hash switching
Overrides the ability of the anchor location element
It is not very beautiful. There will be problems if the data transmitted after the # is complex

History providespushState 和 replaceStateTwo methods to record the state of the route that change the URL without causing a page refresh
History provides a PopState event similar to the Hashchange event, but the PopState event is a little different: a POPState event is triggered when a URL is changed forward or backward by the browser, via pushState/replaceState or<a>Tag URL changes do not trigger popState events. Fortunately, we can intercept the pushState/replaceState call and<a>Tag click events to detect URL changes, so listening for URL changes can be done, just not as convenient as hashchange.
pushState(state, title, url) 和 replaceState(state, title, url)All accept the same three parameters:
State: Data that needs to be saved. This data can be retrieved in event.state when the popState event is triggered
Title: title, basically useless, usually pass null
Url: Set the URL for the new history. The origin of the new URL and the current URL must be the same. Otherwise, errors may occur.

Simple to use, more beautiful
pushState()The new URL can be any URL of the same origin as the current URL, and the hash can only change the content after the #, so you can only set the URL of the same document as the current URL
pushState()Urls that are exactly the same as the current URL are added to the history stack, and the content after hash# must be modified to be added to the new stack
pushState()Can be achieved bystateObjectArguments add arbitrary types of data to records, whereas hash can only add short strings
pushState()Additional title attribute can be set for subsequent use
The URL of the front end must be the same as the URL of the back end; otherwise, a 404 error will be reported
Older browsers have compatibility line issues due to the History API