Comments (9)
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.
from history.
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. :-(
from history.
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.
from history.
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.
from history.
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!
from history.
@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.
from history.
@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.
from history.
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.
from history.
@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)
from history.
Related Issues (20)
- Named exports donβt work with Node.js ESM support HOT 1
- Sourcemaps are blank HOT 1
- Use History in redux actions HOT 2
- Location type should have template for unknown for state HOT 3
- doing history.go() does NOT trigger a blocker callback handler HOT 1
- Did TS declaration file disappear for v4? HOT 4
- Wrong action after clicking on Forward button in browser HOT 3
- Need history.BackTo(string)
- Is it possible to access the history bundled into React Router? HOT 1
- globalHistory.pushState function excuted failed in baidu.app
- [v6] Missing hashType={"noslash"} of HashRouter HOT 3
- [react-router-dom v6] HashRouter support HOT 1
- Add index property to BrowserHistory, HashHistory and corresponding Update
- Why `history.length` is gone? HOT 7
- createBrowserHistory() breaks history URL on iOS 11
- history
- is this project abandoned? HOT 2
- Navigate replace without generate new location.key
- hash history url is not parsed correctly with query params
- ReferenceError: document is not defined in Next.JS HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from history.