In this lesson we'll look at hashHistory which uses a hash hack to track our route changes vs browserHistory which delivers clean urls, but requires server work to implement
We're looking at our standard, three page, single page application, and we're using hash history to keep track of the URL history in our router. In production, what we want to use is something called browser history.
If I reload over here, we can see that, rather than getting the hashtag path, we'll just get a very clean /about and /contact. In order to use this, though, you're going to need to set up your server to always return your application at any route.
Generally speaking, that means in an express application, you're just going to return index HTML every single time a URL is called. Then the single page application will take care of the routing.
The downside to not using hash history in these lessons, where we're not really going to go into setting up your server, is that when we jump to a path like /about and reload, we're not going to get that path. If we switch back to hash history, and go back to our root path, we can get to our individual routes.
We are going to get this /hashtag, /our path name, then a query string, with a parameter of underscore K, followed by some form of hash that's being used to keep track of our path so that, as we navigate through, we can simply use our back and forward buttons to navigate through that.