react-router: Why the preference for browserHistory over hashHistory?

Question

I\'m relatively new to React; apologies if this is a really naive question.

What are the technical advantages to browserHistory that make it prefer

Answer 1

In some cases hashHistory is fine - except when you start dealing with server-side logic that needs to know a full URL of the original request.

Browsers do not send the #hash part of URL in any of HTTP requests.

Therefore server-side (i.e. NodeJS) would not know what #hash was in the URL when user requested a page.

A good example is user trying to load a page that requires a login (via oAuth etc.). Before user is taken to a separate website for authentication, you app's server-side would tell the authentication vendor what URL redirect user to after a successful login (usually it is to the original URL requested as most websites do this). If you were to use hashHistory - server-side would know only the bits before # symbol and would redirect user to the main page of your app and not a sub-page that user wanted to load.

I hope that makes sense.

Answer 2

What are the technical advantages to browserHistory that make it preferable over hashHistory?

It allows you to have a server side fallback which:

1. Allows the first page visited to initialize with HTML (rather than having to fetch all the data with Ajax) which gives better performance
2. Means the site keeps working even when JS fails (this is also better for search engines).

This comes at the cost of having to write the server side code to build pages in the same way that the client side code does. Without that, using the history API is objectively worse … but the URLs are, very subjectively, nicer so lots of people do it without the server side half anyway.

Answer 3

One reason browserHistory is preferred over hashHistory is that it is better for deployment and production. hashHistory "works" by adding a unique key at the end of the url and creates a "history" for this by using these keys to keep track of your current session.

browserHistory looks much cleaner without the #, but in order to get this set up, you need to configure your server such that it can handle the URLs you intend to provide it.

Hope that helps!