A brief talk about React Router's history

If you want to understand React Router, you should first understand history. More specifically, it is the history package that provides core functionality for React Router. It makes it easy to add location-based navigation to your project on the client side, a feature that is critical for single-page applications.

npm install --save history

There are three types of history: browser, hash, and memory. The history package provides methods for creating each type of history.

import {
 createBrowserHistory,
 createHashHistory,
 createMemoryHistory
} from 'history'

If you use React Router, it will automatically create the history object for you, so you don't need to interact with history directly. However, it is still important to understand the different types of history so that you can decide which one to use in your project.

What is history?

No matter which history you create, you'll end up with an object that has almost the same properties and methods.

location

The most important attribute of the history object is location. The location object reflects the "location" of the current application. It contains attributes derived from 'URL', such as pathname, search[Note 1], and hash.

Additionally, each location has a unique key associated with it. 'key' is used to identify a specific location and store data in a specific location.

Finally, locations can have state associated with them. This is fixed data and does not exist in the URL.

{
 pathname: '/here',
 search: '?key=value',
 hash: '#extra-information',
 state: { modal: true },
 key: 'abc123'
}

When a history object is created, the location needs to be initialized. The process is different for different types of history. For example, browser history will parse the current URL.

One location to rule them all?

While we can only access the current location, the history object keeps track of a set of locations. It is because of the ability to add locations and access any location in the array that history is called "history". If history can only record the current location, it should be called "present".

In addition to a set of locations, history also stores an index value that points to the current corresponding location.

For memory history, they are defined directly. As for browser history and hash history, the arrays and indexes are controlled by the browser and cannot be accessed directly [Note 2].

Navigation method <br /> It can be said that the navigation method is the finishing touch of the history system with the location attribute. Navigation allows you to change the current location.

Push Method
The push method enables you to jump to a new location. By adding a new location after the current location, any 'future' locations will be cleared (previously created locations after the current location by the back button).

By default, when you click <Link>, the history.push method is called to navigate.

history.push({ pathname: '/new-place' })

replace
The replace method is similar to push, but instead of adding a location, it replaces the location at the current index. The 'future' location will not be cleared.

Use replace when redirecting. This is also the approach used in React Router's <Redirect> component.

For example, when you navigate to page 2 by clicking a link button on page 1, page 2 may redirect to page 3. If the push method is used, clicking the back button will return from page 3 to page 2 (with the potential to redirect to page 3). If the replace method is used, page 1 will be returned directly from page 3.

history.replace({ pathname: '/go-here-instead' })

go, go, go
Finally, there are three methods with 'go', namely goBack, goForward and go.
goBack returns one level of page. In fact, it reduces the index value of history by 1.

history.goBack()

goForward is the opposite of goBack. Go forward one page. This only takes effect when you have a 'future' location, i.e. when the user clicks the back button.

history.goForward()

go is a powerful method that includes the functionality of goForward and goBack. Passing in a negative number will move backwards, and passing in a positive number will move forwards.

history.go(-3)

monitor!

Using the observer mode, history will send a notification when the location changes. Each history object has a listen method that accepts a function as a parameter. This function will be added to the array of listener functions stored in history. When the location changes (such as when the code calls a history method or the user clicks a browser button), the history object will call all listener methods. This allows you to set up code to update when the location changes.

const youAreHere = document.getElementById('youAreHere')
history.listen(function(location) {
 youAreHere.textContent = location.pathname
})

React Router's router component will subscribe to the history object so that it can re-render when the location changes.

Linking things together

Each history class has a createHref method that takes a location object and outputs a URL.
Internally, history is navigated through location objects. However, like the anchor element (a), it does not know the history package, nor does it know what the location object is. In order to make the generated HTML still navigable without the need for history. We have to generate the actual URL.

const location = {
 pathname: '/one-fish',
 search: '?two=fish',
 hash: '#red-fish-blue-fish'
}
const url = history.createHref(location)
const link = document.createElement('a')
a.href = url
// <a href='/one-fish?two=fish#red-fish-blue-fish'></a>

The above covers the basic history API. Although there are other properties and methods that have not been introduced, the above methods can help you understand how the history object works.

Bringing it all together

There are still differences between different types of history, which requires you to consider choosing a history that is suitable for your project.
Between the three of them, any use case should be covered.

In the browser

Both browser history and hash history are used in browser environments. They interact with the history and location web APIs, so the current location is the same as what is shown in the browser address bar.

const browserHistory = createBrowserHistory()
const hashHistory = createHashHistory()

The biggest difference between the two is the way they create a location from a URL. Browser history uses the full URL[Note 3], while hash history only uses the part of the URL after the first hash.

// Provide the following URL
url = 'http://www.example.com/this/is/the/path?key=value#hash'
// Location object created by browser history:
{
 pathname: '/this/is/the/path',
 search: '?key=value',
 hash: '#hash'
}
//The location object created by hash history:
{
 pathname: 'hash',
 search: '',
 hash: ''
}

Using hashing

Why do you need hash history? In theory, when you navigate to a URL, there must be a corresponding file on the server. For dynamic serving, the requested file does not need to actually exist. Instead, the server examines the requested URL and decides what HTML to return.

However, static file serving can return files directly from disk. The most dynamic thing static serving can do is return the index.html file from a directory when the URL specifies the directory.

Due to this limitation of static file serving, the simplest solution [Note 4] is to use only one real location on the server to return the user's retrieval request. Of course, having only one location means that your application only has one URL, so you can't use history. To solve this problem, hash history uses the hashed portion of the URL to read and write the location.

// If example.com uses static resource service, these three URLs will get the same data from // /my-site/index.html http://www.example.com/my-site#/one
http://www.example.com/my-site#/two
// However, due to the use of hash history, the locations of the three in the application are different.
// Because the location depends on the hash part of the URL { pathname: '/one' }
{ pathname: '/two' }

Although hash history works well, it is considered vulnerable to hacking because it relies on storing all path information in the URL's hash. So consider using it only when your website does not have dynamic services.

memory: cache all history

The best part about using memory location is that you can use it anywhere you can use JavaScript.

A simple example is that you can use it in a unit test by running Node. This allows you to test your code without relying on a browser to run it.

What’s even more amazing is that memory history can be used in apps. In react-nativeapp, react-router-native uses memory history to implement location-based navigation.

You can use memory history in your browser if you wish. (Though you will lose the ability to interact with the address bar this way).

The biggest difference between this memory history and the other two types of history is that it maintains its own location. When creating a memory history you can pass in information to initialize the state. This state is an array of locations and the index of the current location [Note 5]. This is different from the other two types of history, which rely on the browser to store this location array.

const history = createMemoryHistory({
 initialEntries: ['/', '/next', '/last'],
 initialIndex: 0
})

Using history to handle those relatively tedious and error-prone tasks for you is a proven approach.

No matter which history type you choose, they are both extremely easy to use and have powerful capabilities for navigation and location-based rendering.

Notes

[1] The search property is a string rather than a parsed object. Since most string parsing packages differ in their use. So history leaves the choice to the developer instead of forcing the use of a certain string parsing package. If you want to learn more, here are some popular ones: query-string, querystring vs. native URLSearchParams

[2] This is a security restriction. In the browser, the location array of history not only contains the visited location information. If the browsing is open, the user's browser history information will be leaked, so it cannot be opened for access.

[3] By default, the path name of the location object created by the browser history is the full path name of the URL. Of course, you can specify a base name for history, in which case this part of the path name will be ignored.

const history = createBrowserHistory({ basename: '/path' })
// Given the path url: http://www.example.com/path/here
// The history object will create the following location
{ pathname: '/here', ... }

[4] In theory, it would be possible to have every valid URL in your application return the same HTML file. While this is fine, it can create a lot of redundant files if all your URLs are static. However, it is not feasible to use a large number of parameters to match a large number of possible addresses for any address.
[5] If the memory history initialization location array and index are not provided, the following default values ​​will be generated:

entries = [{ pathname: '/' }]
index = 0

For most applications this is good enough, but writing ahead to the history is still a very useful method for recovering content.

This is the end of this article about React Router's history. For more information about React Router history, please search 123WORDPRESS.COM's previous articles or continue to browse the following related articles. I hope you will support 123WORDPRESS.COM in the future!