Git Product home page Git Product logo

Comments (21)

sophiebits avatar sophiebits commented on March 29, 2024

(Should this be the default with location="history"? An option? Happy to send a PR.)

from react-router.

ryanflorence avatar ryanflorence commented on March 29, 2024

I prefer hash being the default because I know it will work and I want people feeling productive quickly, not shaving yaks or looking up the API to turn on hash.

As for doing any sort of fallback, you can do your own thing for that:

var routes = (
  <Route handler={App} location={history.pushState ? 'history' : 'hash'}>
    // more routes
  </Route>
);

Feel free to reopen if this doesn't seem reasonable :)

from react-router.

ryanflorence avatar ryanflorence commented on March 29, 2024

We may not be documenting the location property ...

from react-router.

sophiebits avatar sophiebits commented on March 29, 2024

Sorry for being unclear – I didn't mean for location="history" to be the default. I want to use location="history" but have that fall back to setting window.location (i.e., a full page reload) when it's not available, which is not possible with the current implementation of URLStore.

location={history.pushState ? 'history' : 'hash'} sounds pretty good though Backbone also supports reading from the hash in a pushState browser and vice versa which is useful if someone sends you a link. Maybe it makes sense for the getCurrentPath/push/replace functions to be completely pluggable so people can drop in custom logic?

(Non-collaborators can't reopen issues that have been closed by a repo owner.)

from react-router.

ryanflorence avatar ryanflorence commented on March 29, 2024

I see now.

  1. User is in a browser that doesn't support pushState
  2. App falls back to hash
  3. User shares a hash link with a friend
  4. Friend visits page and supports pushState
  5. Nothing works

We could normalize the url and make it work for this scenario, but if we flip it around and have a pushState supporting user share a url with a non-pushState supporting user then we have the same problem.

Is there a way to solve this scenario in both directions? Can an app actually support both users?

from react-router.

sophiebits avatar sophiebits commented on March 29, 2024

Yeah, there isn't a great solution, which is why I suggested having the option to fall back to not using pushState at all and just doing a full page reload when it's not available – then the URLs are always going to match up; it'll just be slow in IE < 10.

(Backbone's router can interpret both urls from pushState /about and from setting the hash /#/about, but if you start at a URL like /about in a non-pushState browser then you end up going to /about#/profile when you click on links which is super weird and one reason that I don't really want to do that, though it would be nice if it were possible.)

from react-router.

ryanflorence avatar ryanflorence commented on March 29, 2024

Ah, yeah that seems fine. Could do "history", "hash", or "disabled" ... or we just fallback as you say.

Sent from my iPhone

On Jun 29, 2014, at 2:08 PM, Ben Alpert [email protected] wrote:

Yeah, there isn't a great solution, which is why I suggested having the option to fall back to not using pushState at all and just doing a full page reload when it's not available – then the URLs are always going to match up; it'll just be slow in IE < 10.

(Backbone's router can interpret both urls from pushState /about and from setting the hash /#/about, but if you start at a URL like /about in a non-pushState browser then you end up going to /about#/profile when you click on links which is super weird and one reason that I don't really want to do that, though it would be nice if it were possible.)


Reply to this email directly or view it on GitHub.

from react-router.

mjackson avatar mjackson commented on March 29, 2024

@spicyj I'd be ok with including this feature. Seems like you'd only need to modify URLStore.push/replace in order to accomplish something like what you're saying. Ideally this will just be an implementation detail and users can still just use "history".

from react-router.

ryanflorence avatar ryanflorence commented on March 29, 2024

We can't mimic replaceState with page reloads can we?

Sent from my iPhone

On Jun 29, 2014, at 8:36 PM, Michael Jackson [email protected] wrote:

@spicyj I'd be ok with including this feature. Seems like you'd only need to modify URLStore.push/replace in order to accomplish something like what you're saying. Ideally this will just be an implementation detail and users can still just use "history".


Reply to this email directly or view it on GitHub.

from react-router.

mjackson avatar mjackson commented on March 29, 2024

Actually, I think we can. We're already using window.location.replace to do it with hash navigation. I imagine it would work the same way.

from react-router.

sophiebits avatar sophiebits commented on March 29, 2024

@mjackson I think @rpflorence's solution of explicitly specifying location={window.pushState ? "history" : "disabled"} is pretty reasonable for the use case I asked for, though it doesn't quite do the trick if you want to fall back to hash and be able to read from either place.

from react-router.

sophiebits avatar sophiebits commented on March 29, 2024

That is – it's valuable to know as a user that you're getting full page reloads; that fact shouldn't be hidden away.

from react-router.

ryanflorence avatar ryanflorence commented on March 29, 2024

For clarity, we are discussing two things here:

Options for browsers not supporting HTML5 history, we can:

  1. fallback to page reloads when unavailable
  2. provide a 'disabled' setting and have the developer configure the fallback themselves

Some thoughts concerning the router allowing reading hash to history and history to hash urls:

  • We can easily convert hash urls to history urls.
  • You can't go the other way without creating super weird urls (maybe reload at root?)
  • It would need to be an option because there is a valid use case to use hashes with HTML5 history (like they were original intended, links to anchors on the page)

from react-router.

sophiebits avatar sophiebits commented on March 29, 2024

Agree with everything you have written there. I think it's valuable to have these as config options because it seems there are different pros and cons here depending on your browser support and server setup (e.g., reloading at the root makes more sense if the server is very fast, less sense if it's a big perf hit).

from react-router.

ryanflorence avatar ryanflorence commented on March 29, 2024

I'm leaning toward not mingling hash and history urls.

I like the simplicity and consistency of using window.location as the fallback, rather than hash. This way users on any browsers can share urls with consistency. There is only one URL that will work, and then the hash can still be used for its original intent.

from react-router.

mjackson avatar mjackson commented on March 29, 2024

Sure, it's simpler and more consistent. I like that too. But it presents new users with a problem because now they need to either change their server config to serve the same page at different URLs or explicitly specify hash location to get it working the first time.

from react-router.

ryanflorence avatar ryanflorence commented on March 29, 2024
  • The default of our router would still be hash
  • This only happens if they switch to location="history", in which case they already need a server change.

from react-router.

ryanflorence avatar ryanflorence commented on March 29, 2024

I'm 👍 on falling back to window.location for non pushState supporting browsers.

@spicyj any interest in making this happen?

from react-router.

kompot avatar kompot commented on March 29, 2024

Just a thought. Upgrade to location="history" if it's available (e. g. user with an old browser sends a link to a user with a modern browsers).

from react-router.

ryanflorence avatar ryanflorence commented on March 29, 2024

We can know the browser supports it, but we can't know if the server is configured to deal with it. We know hash works all the time.

from react-router.

ryanflorence avatar ryanflorence commented on March 29, 2024

Also

  • we don't want two urls to the same thing
  • people using history may use hash for it's original intent

from react-router.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo 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.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.