11

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

What are the technical advantages to browserHistory that make it preferable over hashHistory? For example, is there a major performance/efficiency boost from it using the History API?

The docs state that browserHistory is recommended, even though this comes at the cost of the additional server config and needing to hard-code or configure your base URL for different servers via basename.

hashHistory "just works", however, regardless of the base URL from which the files are served. No server config needed. Bundle your app, host it from any URL/path on a server, good to go.

It might be good if the docs went a bit further in explaining why it browserHistory is recommended even though it involves more complexity.

taion
  • 2,827
  • 1
  • 14
  • 22
clint
  • 14,402
  • 12
  • 70
  • 79

3 Answers3

14

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.

Romasato
  • 314
  • 2
  • 7
  • OK but in your example the action "taken to a separate website for authentication" is done by the client's routing system --through some sort of navigateTo action-- which in turn can be tweaked to get the # part of the url before the redirection and convert it to a ?urlAfterLogin "real" parameter ? – jeancallisti Nov 17 '21 at 08:58
  • Client-side app does not always know or can predict when it will be taken to authenticate the User - it is usually a server-side HTTP 301 redirect to auth page. In a single-page app scenario, yes, you could work around and implement the extra logic to store #hash and re-apply it after authentication. But that is extra logic to worry about - but may be the only option if you are maintaining a big app and refactor is not an option. – Romasato Mar 29 '22 at 10:42
4

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!

Benny
  • 41
  • 2
3

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.

Quentin
  • 914,110
  • 126
  • 1,211
  • 1,335