Do not hijack links to ids within the page?

[benjamintd]

I am using an external react component that has semantic links <a href='#'>...</a> that trigger a custom provided callback.

The callback uses preventDefault on the event, but the link is still being hijacked and returns to the top of the page.

The expected behavior is to execute the callback without going back to the top - something that I could do if I had access to the link and used data-no-hijack. However that's something that I cannot do with an imported component.

Is there any case when we'd want a link with href='#' or href='#id' to be hijacked? Or would it be a good rule to add to the skipFilter here: https://github.com/mapbox/batfish/blob/a50eea4fbd1b21f4f11bc7e63111e43769d6b9ad/src/router.js#L74

[davidtheclark]

The callback uses preventDefault on the event, but the link is still being hijacked and returns to the top of the page.

I guess that's because this Batfish attaches the link-hijacking listener before your component applies its hijacker. I don't know of a way around this — like, if we could ensure the link-hijacking listener was invoked last 😕

Is there any case when we'd want a link with href='#' or href='#id' to be hijacked? Or would it be a good rule to add to the skipFilter here:

That might work great! We'll have to ensure that it works with the existing use-cases (documentation especially).

Another idea sparked by your problem, @benjamintd, is to add a hijackLinks option in the Batfish configuration the defaults to true. If a user is having trouble with the link hijacking because of a special case (like yours), they could then turn it off and take control of links themselves.

[davidtheclark]

In some documentation that relies internal fragment linking, I added to skipFilter so all links with URL fragments (starting with #) were not hijacked —— and it seemed to work just fine.

So here's what I'm thinking is the plan:

• Add an option to link-hijacker to skipUrlFragments.
• Use that option in Batfish.
• Add an option to Batfish, hijackLinks, defaulting to true.
• We could also add the functionality that data-no-hijack disables hijacking on an element and all its children — so if hijacking goes wrong in just one place, you could add that attribute to a wrapper element.
• I'm thinking we should change data-no-hijack to data-batfish-no-link-hijack. Namespacing seems better, as long as we're still young and making breaking changes.

@jfurrow @lshig what do you think of these proposals?

[jfurrow]

• Add an option to link-hijacker to skipUrlFragments.
• Use that option in Batfish.
• Add an option to Batfish, hijackLinks, defaulting to true.

👍 I definitely think these are good ideas!

• We could also add the functionality that data-no-hijack disables hijacking on an element and all its children — so if hijacking goes wrong in just one place, you could add that attribute to a wrapper element.

This also sounds great, but I wonder about the implementation — would you have to traverse all of the ancestors of the clicked anchor element to check for this attribute? If so, I think that might be too heavy to do before the user's click is handled. But maybe there's a faster way to do it!

• I'm thinking we should change data-no-hijack to data-batfish-no-link-hijack. Namespacing seems better, as long as we're still young and making breaking changes.

👍