CODEWITHSUNDEEP
react-router
clint
clint

Reputation: 14534

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

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.

Upvotes: 11

Views: 7332

Answers (3)

Quentin
Quentin

Reputation: 944556

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.

Upvotes: 3

Romasato
Romasato

Reputation: 314

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.

Upvotes: 14

Benny
Benny

Reputation: 41

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!

Upvotes: 4

Related Questions