Preserve hashes on Transition if hash-routing is off about router5

[troch]

So you just want the hash part of an URL to be kept through route transitions? What about it changing and hashchange events?

[JonathanWolfe]

I figure that'd be ignored by Router5 so that the browser can scroll to those elements or other JS events can process (like if the hash is being used to monitor which tab is open from jQuery UI).

Examples:

/example/path#hash -> /example/path#secondHash = no router5 events
a[href="/example/path/#hash"] -> click = Router5 navigate, then re-attach hash

[troch]

I think that no matter what, when changing the hash of a URL, it will push to your history, and trigger popstate events as well as hashchange events. I am not sure how I would concile the two together.

[JonathanWolfe]

Well it currently already has the correct behavior, except for removing the hash when navigating to a URL or initializion.

You can see what I mean by going to https://hopspot.com and clicking the terms of use and privacy policy links.

[troch]

OK, so it needs to survive the router starting. What about navigation thereafter?

[JonathanWolfe]

That's why I had the idea of treating hash as a special param name. So when navigating, if it's present in the navigate call, it gets amended to the URL. This lets Router5 SPAs retain anchor linking.

[dogoku]

Is this feature something that you are considering? I have a use case similar to the above, where I'm using HTML5 mode + history and I'd like to use hash either as suggested above (special parameter) or as part of my route definition. E.g:

var routes = [
    { name: 'first', path: '/:first'},
    { name: 'first.second', path: '/:second'},
    { name: 'first.second.third', path: '/:third'},
    { name: 'first.second.third.hash', path: '#:hash'}
];

Specifying hash in routes was my initial idea, but after seeing what @JonathanWolfe suggested, I am happy with that too.

[troch]

I am considering it but I haven't got the time until now (this week and next week) to have some thinking about it. I'm not sure yet what I should support: preserving hash part of the URL, or introducing a hash parameter in route definitions.

[troch]

It's not covered by the v4 release. I think I know how to do it, I'm closing this issue for now as the solution only involves work on path-parser and route-node packages. I don't have a timeline yet on when I'll be able to support this.

[dogoku]

Sorry @troch for resurrecting this issue, but I was wondering if this bug will ever be fixed?

At the moment I have to do a lot of coding around browser plugin in order to preserve hashes:

• Ignore links that are on the same path, but have different hashes (i.e links to elements on page)
• Before calling navigate, save the new hash and do history.replaceState after transition end
• Add popstate listener before router5, save hash and do history.replaceState after transition end

Given that preserving hashes is the native behaviour of the browser, I don't see why router5 should be touching the, if useHash is false (I think everyone in this thread agreed to that)

If you will not be changing this behaviour, it would be good to know, so that I can fork the browser plugin and maintain it locally, which is preferable to writing code around it.

Thanks :)

[troch]

@dogoku it should preserve hash, but only on start. Are you talking about being able to navigate with a hash?

[dogoku]

Yes, the initial load is handled correctly.

My concern is during History Forward/Backward (i.e popstate), since the hash gets removed by the browser plugin.

Any clicked links, I handle in my app, so I am ok with preserving the hashes before calling navigate, as link click handling was never something the browser plugin did anyway.