MoOx / pjax

Easily enable fast Ajax navigation on any website (using pushState + xhr)
MIT License
1.46k stars 125 forks source link

Make a special event or something when current url is clicked again #17

Closed MoOx closed 6 years ago

MoOx commented 10 years ago

This can make sense if you have transition (eg: slide) on user click on a link that is the same url that it is already. Doing nothing is a bad idea, so a different kind of effect should be used to not use a slide just to reload the current page.

Ref #14

darylteo commented 8 years ago

This can be dangerous in the context of #7 - if the href results in a redirect, it won't detect "the same url". Only the application will know what is the "active" link - I believe the responsibility of this should lie with the application - combined with the changes I just made for #5 this can be done using preventDefault.

BehindTheMath commented 6 years ago

Currently, by default, if the href of the link is the same as the current URL, Pjax will do nothing. The user has the option to set options.currentUrlFullReload to true, in which case it will trigger a full page reload.

I agree with @darylteo, and I don't think Pjax should do anything different in this scenario. If anything, it should be left to the user.

If I'm not mistaken, if the user wants some custom behavior in such a situation, they can add a click listener to the link(s). When it's called, check if the href and URL match, and if yes, use preventDefault to stop the event from continuing on to Pjax, and then do whatever custom behavior is desired.

Does that make sense? Should we add a custom event for such a situation?

CC: @robinnorth

robinnorth commented 6 years ago

We could add a custom event (triggered on the link or document, like all the other pjax:* events?), but equally you can already achieve custom behaviour with click event handlers without the need to listen for any special events. The following code (adapted from example.js) demonstrates that:

document.addEventListener("DOMContentLoaded", function() {
  var links = document.querySelectorAll(".js-Pjax");

  for (var i = 0; i < links.length; i++) {
    var el = links[i]

    el.addEventListener("click", function(e) {
      if (el.href === window.location.href.split("#")[0]) {
        e.preventDefault();
        console.log("Link to current page clicked");
      }
    })
  }

  var pjax = new Pjax({
    elements: [".js-Pjax"],
    selectors: [".body"],
    cacheBust: false
    //currentUrlFullReload: true
  })
  console.log("Pjax initialized.", pjax)
})

(Note that if cacheBust is set to true, both the example check for the requested link href being the same as the current page's URL and the internal check that Pjax uses (from which the example was lifted) will not work, due to the query string appended to force a cache bust -- this is intended behaviour, IMO)

The only advantage of firing a custom event is removing the need for a user to check if the requested link href corresponds to the current page. However, I think @darylteo is arguing that the application should be allowed to determine that for itself, rather than letting Pjax do it.

I also think that given that currentUrlFullReload is opt-in behaviour, it might be worth keeping it in (If we remove it, we need to do it in a minor version bump, at least).

BehindTheMath commented 6 years ago

I think that's an excellent summary. I'm going to add some documentation like that to the README, and leave currentUrlFullReload the way it is.

robinnorth commented 6 years ago

Great, sounds good to me.