Reputation: 14534
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
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:
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
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
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