Handling link clicks to the current URL?

[danielcompton]

We have a hamburger menu which takes over the whole page on mobile. Each of the links in the menu is just a regular <a> with a path another route. When the user clicks on a link to a page they're not currently on, our dispatch-fn is called and we navigate to the page we want to show.

The problem we're having is that if they click a menu link to a page that they're already on, the history update is short circuited. This prevents the NAVIGATE event from firing, so we never get a chance to act on the click in our normal route handling code. This means we never get an event to hide the menu.

I can see a few ways we can fix this on our side:

1. Special case the links to the page that we're on and intercept the click before it makes it to pushy. Then we can just close the menu in our own code. This feels a bit gross though.
2. Make the closing of the menu separate from our navigation code and always close the menu on any click to any of the links. This seems maybe ok?

I'm not sure if we just have a bad architecture here and should be structuring our code a bit differently. OTOH, it does seem like apps might want to be able to respond to link clicks to the page they're already on?

What do you think? Is this something that would make sense for pushy, or does it mix concerns badly?

[shen-tian]

Sounds like it's a question of what meaning can we give to an anchor link to the page your are already on? Is it always a no-op, or same as clicking on that link from elsewhere (some sort of idempotentncy)?

Having thought about it whole of 5 minutes, the 2nd one sounds more appealing...

In your situation, closing the side menu is equivalent to reseting the temporary state that only lives between navigations.

As a workaround, is the data-pushy-ignore attribute useful?

pushy/src/pushy/core.cljs

Line 123 in 0f5da40

(or (not (.hasAttribute el "data-pushy-ignore"))

[danielcompton]

Thanks, I'll take a look at how we might use data-pushy-ignore as part of a workaround.

I did some investigation on this. Normal websites (that aren't using HTML5 History) treat a click on a link to the current page as a full page reload, but don't add a new entry to the browser history (I checked Safari, Chrome, and Firefox). I think your second option sounds like it would do the same thing, and would fit the user and programmers mental model of what should happen on a link click to the same page.

[shen-tian]

Do you know what accountant does, by any chance?

[danielcompton]

Unsure, I'll have to check.

[w9]

I am having the exact same question. @danielcompton, did you find any elegant solution?

[danielcompton]

I don't remember if I did, but I suspect not.