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

New Issue

2014-09-15T23:50:01-05:00

MoOx commented

2014-09-15 23:50:01 -05:00

(Migrated from github.com)

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

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

2016-01-04 19:21:50 -05:00

(Migrated from github.com)

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

2018-01-31 22:19:30 -05:00

(Migrated from github.com)

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

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

2018-02-01 06:17:39 -05:00

(Migrated from github.com)

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).

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: ```js 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

2018-02-01 13:43:05 -05:00

(Migrated from github.com)

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.

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.

🎉 1

robinnorth commented

2018-02-01 15:01:42 -05:00

(Migrated from github.com)

Great, sounds good to me.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: iLoveElysia/pjax#17