Choo: handling both hash routing & anchor links

[sethvincent]

As I'm porting minidocs to choo v5 I'm working on making choo v5 support both hash routing & navigating to anchor links if they are present on the page.

The tricky part is that when the router is first called, the element isn't available on the page yet: https://github.com/yoshuawuyts/choo/blob/master/index.js#L50

So there's not a way to check if an id is available to scroll to before the router is called.

Thoughts on how to implement this?

[sethvincent]

Forgot to add:

Current behavior of createLocation function is to rewrite a url fragment like /about#install to /about/install before it is passed to the router.

The goal (I think) is to avoid this behavior when the #install id exists on the page, and only tell the router the pathname in that case.

[jenslind]

Instead of checking if the id exists, perhaps we could prefix the hash if we want to use it as an anchor. Something like this: /route#anchor:id, just a thought.

[yoshuawuyts]

Heya, thanks for the suggestion! - Personally I wouldn't want a framework
to tell me how to write my links, but just work as expected. Think we
should explore making that work first (think it might already? not sure,
not tested) and only if that's truly impossible look for different options.
Hope that makes sense ✨

On Sat, Apr 8, 2017 at 1:36 AM Jens Lind [e-mail] wrote:

Instead of checking if the id exists, perhaps we could prefix the hash if
we want to use it as an anchor. Something like this: /route#anchor:id,
just a thought.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/yoshuawuyts/choo/issues/440#issuecomment-292676011,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACWlej12aoysc71HoelYNBLGEnrJqeHvks5rtshqgaJpZM4MnbQp
.

[jenslind]

Totally agree!

Another thought off the top of my head.. 💭
Having # behaving differently depending on page content feels a bit weird to me.
What about an option to turn off support for # in routes, i.e. do not turn /some#route into /some/route. And let the user make the choice of treating # as a path or anchor.

🐈

[yoshuawuyts]

@jenslind generally I'm not a big fan of options, but as per #489 by exposing the app._createRoute method the behavior can be changed if people wish to. Hope this good enough! :D

[hbrls]

Do you have a hash routing example? I cannot get it to work.

[bcomnes]

Simple example https://github.com/hypermodules/hyperamp/blob/master/renderer/index.js

[LJNGDAHL]

As a fairly new user of choo (and so far overall super impressed by it 🎉) I’m having a bit of trouble understanding the way anchor links are handled. How come you have decided to turn /some#route into /some/route?

It took awhile for me to wrap my head around what the section Hash routing in the README.md really meant (and how to get anchor links working like they usually do) – but that might just be me as a confused newbie. 🤔 ✨

[johnelliott]

It seems like the always-there default to top (<a href="#">top</a>)is does not with by default with nanohref. It would be nice if that worked unless a route is set on #.

[afincato]

hash routing works 'out of the box' except when you are at the root page and have a link bringing somewhere to that page — in which case a / is added before the #link.

how do you prevent that?

[istvanvasil]

hash routing works 'out of the box' except when you are at the root page and have a link bringing somewhere to that page — in which case a / is added before the #link.

how do you prevent that?

Any success on this?
@afincato