Are url hashes supported with pushState: true?

[xrado]

/login#something ...works /#something ...is not found, while / works

and on initial load /#something is replaced with /something

[xrado]

Actually this happens in location-bar lib on https://github.com/KidkArolis/location-bar/blob/master/location-bar.js#L198 on start replaces /#something with /something

[xrado]

ok I solved it by settings location to BrowserLocation with custom options. Setting hashChange: false do the trick

const router = Cherrytree({
    interceptLinks: true,
    pushState:true,
    location: new Cherrytree.BrowserLocation({pushState: true, hashChange: false, root: '/'})
})

[xrado]

ahh.. that only works for initial router call, further transitions don't work anymore :/

[KidkArolis]

You want to use both pushState and hashes at the same time? As you've noticed - cherrytree in pushState mode will replace #/foo to /foo on startup. I will implement an option to disable this behaviour. This way, cherrytree will just use the URL as is and leave the hash alone. I might even look into exposing the hash as part of the router params.

The tricky bit here is that the automatic fallback to hash behaviour will kind of break. Tbh I don't know if browsers without pushState is still a thing. Perhaps, in this case, the router will go into hash mode and will simply drop the other hash. Would that be acceptable?

[xrado]

I just want to use pushState (without legacy hash change) where urls may also include hashes. An hash as part of router params and option to enable or disable fallback, yes that will be great.

[xrado]

With hashes included what would then happen when you'll navigate to same path and only the hash part will change? Transition won't fire, right? ..just hash part will change in url?

[KidkArolis]

That's a good question, will have to try and find out. If I start passing hash as one of the params, then it might make sense to fire a transition (just like if a query param changes). If I don't pass hash as one of the router params to transition middleware, then perhaps I should ignore hash changes. Also - I'm not sure if I can even detect hash changes and push state changes at the same time in any sensible way.

[xrado]

I wouldn't fire transition if only the hash part changes, but url should be updated anyway. It looks like hash change won't fire a page jump (http://lea.verou.me/2011/05/change-url-hash-without-page-jump/) when changed via pushState, but thats ok I guess. If you are using pushState, you control what happens.

[KidkArolis]

Hey, so this is still a very interesting issue for me, as making it possible to utilise hashes in cherrytree sounds like it could be a useful feature, e.g. for anchoring/scrolling to page elements like it's intended, or to encode some clientside params.

I don't have the time to look into how to implement this right away, but I'll keep this issue open for now.