Ignore hash-part in `loadUrl` when `hashChange = false`

[nikcorg]

I'm working on an app where we rely solely on pushState. For browsers who don't support it, we simply fall back to regular page loads.

Why I opened an issue, is really because the way Backbone handles routes declared in the Router.routes hash. As it is now, Backbone will intelligently treat hash URLs equivalent to non-hash URLs, even when pushState is true. On Backbone.history.start() a possible hash containing URL is replaced with a non-hash version. All well and good.

But the default behaviour of loadUrl is to treat the URL as a complete unit, which becomes a problem if you also want to support URLs with hashes in them. In this case a route will not match, unless you declared it as a RegExp in Router.initialize.

To tackle this, I currently override the default loadUrl with a version that strips the hash before calling the original loadUrl.

Personally, I would be interested in seeing either a new configuration setting that would enabled this behaviour in Backbone core, or finding a combination of current configuration that would have this behaviour.

I would definitely be interested in contributing a PR for this, should this be deemed a worthy idea. Otherwise, I suppose I'll just keep monkey patching...

[tgriesser]

Hey @nikcorg, thanks for the issue. If you try the latest develop version, I believe the behavior you're looking for is enabled with {pushState: true, hashChange: false} - take a look at #2538 and #2565 for more information.

[nikcorg]

Hey @tgriesser

Looks like the PRs you reference address the issue of ignoring the hash-part in the sense that it doesn't convert the URL to a non-hash version, but my concern is really about matching the routes in Router.routes hash in loadUrl, when the URL contains a hash.

The matching is currently done using the complete URL (including the hash) and AFAICT neither of the two issues mentioned address that.

To achieve what I'm looking for, the change would have to either happen in getFragment, or _routeToRegexp, but as the latter is run after routers are configured, the former is probably the only option.

[tgriesser]

@nikcorg - would you be able to provide a failing test case with the behavior you're looking for?

[nikcorg]

Absolutely. I'll start working on it.

[nikcorg]

Hey @tgriesser

I think this test case should demonstrate what I mean. There is a commit in my fork (https://github.com/nikcorg/backbone/commit/25585919f1d106bdc6d7d81d24e99a3a884e9c76), or you can copy-paste from below.

test("#2765 - URLs with hashes will never match hashless route", 1, function () {
    Backbone.history.stop();
    Backbone.history = _.extend(new Backbone.History, {
        location: location
    });
    var Router = Backbone.Router.extend({
        routes: {
            // Matching `foo` despite the hash `#bar` is the desired effect when `pushState == true && hashChange == false`
            "foo": function () {
                ok(true);
            },
            // ...but the route is matched with the complete url, so `foo#bar` is triggered
            "foo#bar": function () {
                ok(false);
            }
        }
    });
    var router = new Router();
    location.replace("http://example.com/bar");
    Backbone.history.start({
        pushState: true,
        hashChange: false
    });
    Backbone.history.navigate("foo#bar", true);
});

[nikcorg]

Urgh... sorry for the noise. I sailed the fail boat today.

[braddunbar]

Hi @nikcorg! Thanks for the issue. I can see the issue you're describing (thanks for the test case) but I'm wondering why you would need this functionality. Why not just use navigate('foo') instead? In other words, why do you need to support a hash in the url?

I'll submit a patch to consider, but I'm not yet certain this is a good direction.

[nikcorg]

@braddunbar

I don't want to simply navigate("foo") because I do want the hash in the url. It's useful for bookmarking/sharing purposes, as well as scrolling the page to the intended position in the triggered route. I merely want to be able to use hashes and still be able to match the defined routes like the hash wasn't there.

If you want to generalise the issue, my desire is to have the defined routes match either the hash part or only the path part of the URL, depending on configuration.

I can definitely submit a patch as well. I didn't yet, because I wanted some feedback on the idea first.

[braddunbar]

Pulled in #2766. @nikcorg I changed #navigate to strip the query and hash before matching but after building the url. Seems to work well enough.

[nikcorg]

That's brilliant. Thanks!