Is it possible to have an option that detects HTML5 History or falls back to hash automatically?

[jeffbski]

Is it possible to have an option that detects HTML5 History API or falls back to hash automatically?

I would think that would be what most people would prefer to do these days. I think ember has that type of functionality with its "auto" location option.

http://emberjs.com/api/classes/Ember.Location.html

[mjackson]

To quote the react-router docs:

Why don't you just fall back to HashLocation?

Because we'd end up with multiple urls for the same UI, and as users with different location support share urls they become non-deterministic for the router to switch back and forth.

Additionally, many HistoryLocation apps will want to take advantage of what the hash is actually intended for: linking to specific elements in the page. We don't want to break this valuable feature of the web.

[jeffbski]

Ok, those are valid points, but that could be a developer's choice. We can just document the concerns and make it an option.

For those browsers that would use HTML5 History then they will use hashes appropriately. It's only for the old browsers like IE9 where they will be stuck using the hashes for routes. I'd live with the risk that the IE9 and current browsers can't share URL's since over time there will be less and less of those browsers.

While I wish everyone would ditch the old browsers, for some sites that is not yet an option. So we'd be stuck using hashes for everyone while most people could use HTML5 History API.

It's a balance of trying to move things forward (using latest API's) while not totally breaking things for old browsers. Yes, they might not have the full experience (sharing URL's might not work right), but they'd be able to use the site to some effect.

You are basically going to force me to create a 5 line project that wraps this one so I can detect HTML5 History before calling the appropriate routing method. :-(

[jeffbski]

From reading the React Router FAQ you linked
I guess if one is using React Router, then it will default to the RefreshLocation for old browsers, so I guess this is really just an issue for trying to use this library on its own (not with React Router), if I understand that correctly.

[mjackson]

For those browsers that would use HTML5 History then they will use hashes appropriately.

But when a user with a modern browser shares a URL with someone who doesn't have a modern browser, everything breaks.

You are basically going to force me to create a 5 line project that wraps this one so I can detect HTML5 History before calling the appropriate routing method.

@jeffbski All we're forcing you to do is decide what your URLs look like up front. When you're building your app, decide which browsers you want to support. If you need to support IE < 10, then use hash history. Otherwise, use real URLs.

[jayphelps]

FWIW it is indeed possible to support both, but it's a bit more complicated that one would initially think. I wrote it back in the day for Ember and it went through many iterations of bug fixes and design choices. If anyone cares to port it..

http://www.slideshare.net/jayphelps/auto-location
https://github.com/emberjs/ember.js/blob/6bb0cc11519aa00c10cb6f086becb7beb75927d3/packages/ember-routing/lib/location/auto_location.js

I don't have a need for this ability these days so I can't spend the cycles, sorry!

[mjackson]

@jayphelps how do you distinguish between an app that uses browser history with a real hash and an app that uses hash history? Seems impossible. Both will have hashes, but they are interpreted differently.

[jayphelps]

@mjackson Not 100% sure which case you're referring to, but perhaps you're talking about how to distinguish between a hashed URL that needs transformation to a clean history URL and treated as a route, e.g. /#/about and a URL that contains a hash that isn't really a route and shouldn't be transformed, e.g. /about#foo. The way we did it in Ember is requiring that hashed paths start with #/, you can see that here.

It's currently possible in Ember to have doubled up hashes as well, though no built-in utility exists to extract these. e.g. /#/about#foo and /about#foo are both interpreted as /about and the extra hash info is just ignored. A utility could be built into this library to extract the extra hash, available at something like history.hash.

Also, just to clarify, when you boot up the URLs are normalized to the supporting feature. So history supported browsers will transformed hashed routes immediately to pretty history URLs and hash-only browsers will transform pretty history URLs to the hashed version. This is so the user's URL is consistent while navigating around and so shared links don't contain two different routes in them making it confusing to users.

[mjackson]

Thanks for the explanation, @jayphelps. We currently force all hash history URLs to begin with a slash, so we'd probably have to sacrifice that feature in order to take the route you describe here.

[jayphelps]

@mjackson Yup, hmmm..but that doesn't really seem like a true feature to me? Seems like a shortcut to make the code easier to reason at the expense of disallowing hash metadata. e.g. /#foo (index route with foo meta) and /#/about#foo (about route with foo meta)