The location object is an object containing information about the current URL. It is part of the window object- window.location()-and can be accessed through said property. Location object methods are:

window.assign(): this is to load a new document.

window.replace(): removes the URL of the current document from history. It is therefore not possible to use the ‘back’ button to navigate to original document.

window.reload(): reloads the current document. It reloads the page from the cache by default. You can also reload the page from the server by setting the forceGet parameter to true. (The default is false.)

// a basic location object
{ pathname: '/', search: '', hash: '', key: 'abc123' state: {} }

There are two (three) types of history objects. They both do one thing for the react router and that is tell the router which part of the URL to consider when rendering components on the screen.

BrowserHistory looks to the right of the ‘.com’ or ‘.gov’ or ‘.edu’. HashHistory only looks to the right of the # that is included in the URL.

So why would I use one over the other?

Let’s say you have a giant application using Rails. You want to go to a route for /admin that serves up a form. If you are using a server and want to throw on top of it a react router application, you would use HashHistory. Why wouldn’t you want to use BrowserHistory for that?

In general if you do not specify a file in a path you will be served up index.html. If you have a link that will take you to a list, the URL will add the path to the URL. If you refresh the page now you can’t get the page. But if you go to the homepage and click on the link, you do have access.

To explain this we have to talk about the App Lifecycle a little bit:

As stated, when going to a root route, we are given index.html if nothing else is provided. When react router starts up, it looks at the URL and decides what components to show. When a <Link> is clicked , the address bar updates but a new request is not made to the server. Navigating around inside of an application, there aren’t requests being made. With a new path, different components will be shown. So now when we refresh the page, we try to access the server with the new route. In order to make sure we hit the index.html every time before the rest loads we have to specify that.

Setting window.location to a URL will not reload the page if there is a # in the URL. On the other hand, window.location.reload(); will reload the page.

Here is a fix for using BrowserHistory which seems to be the preferred method now:

app.get('*', (req,res) => {res.sendFile(path.resolve(__dirname, 'index.html'))};

This is saying that anytime a get request is made to any address whatsoever, run the function to find index.html and send it back to the user. No matter what route the user is trying to access, send them to index.html. Now, going to any route will send them there first and then render Components. This is how to make BrowserHistory work with a react application.

From Michael Jackson

The take-away: When trying to load a page that requires login, a user is taken to a separate website for authentication. The app’s server-side tells the authentication vendor what URL redirect to use after a successful login. If you were to use hashHistory then the server-side would know only what comes before the hash symbol and would redirect the user to the main page of your app, and not a sub-page.

Also, browserHistory allows the first page visited to be initialized with HTML, instead of fetching with Ajax. This gives better performance. Therefore, when using something in production mode, you may want to use BrowserHistory.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.