Support filtering DOM nodes that will be processed in href()

[jliuhtonen]

Often it is useful to filter the set of links that will be processed by the router. One common case for this is if you are linking to content inside the same domain that is not a part of your application.

This PR implements an optional filtering function that can be given to href() as a parameter. The function receives a DOM node and the truthiness of it's return value will be used to determine whether to call cb and save the url to history using pushState or not.

This also addresses issue 15.

[yoshuawuyts]

Hmm, I quite like the idea behind this - but think it would lag one step behind the solution proposed in #15 - namely that we can be smart about how / when links should be handled.

[jliuhtonen]

Sensible defaults, and ideas suggested in the issue, are definitely good, but sometimes finer control is needed. The need for bypassing processing of links can also be very specific to the app and environment in question, so IMO it is good to provide users the power to choose what gets left out in addition to providing good defaults.

[yoshuawuyts]

Hmm, I'd solve that by being explicit in the links themselves and setting a property similar to:

<a href="/foo/bar" data-router="false">
  my cool link
</a>

Feel that if we expose more API surface here, instead of dealing with the problem in the router we're instead pushing it onto users of this project - which is not quite solving it.

[jliuhtonen]

Exposing a DOM node that's a candidate for routing is not that bad in my opinion, since traversing the DOM etc. is done for the user of the library, but I get your point.

A predefined bypass attribute like data-router="false" would also solve the issue in my case, though it would give less control to other users. Then again you can always write your own href implementation if needed. If this approach is preferred, I can change the PR accordingly.

I'd prefer if the attribute would be false by default (so it being absent would mean that it is not active), so we could use boolean attributes and have a name that would be unlikely to clash with other libraries. What do you think? How about data-sheet-no-routing or data-sheet-external-link?

[yoshuawuyts]

Sounds reasonable, curious to hear other people's opinions on this. Think I'd go for a shorter atrribute though, as 4 words is a bit long. Perhaps:

<a href="/foo/bar" no-routing>my cool link</a>

This wouldn't work in yo-yo / choo straight away tho:

• Boolean attributes choojs/hyperx#14
• seems to ignore html attibutes without assigment choojs/nanohtml#28

So initially it should be written as:

<a href="/foo/bar" no-routing="true">my cool link</a>

You reckon that sounds reasonable? A PR for that would def be appreciated; we can always discuss the exact keywords. ✨ thanks!

[jliuhtonen]

Okay. We'll have to keep data--prefix though to keep the markup valid HTML 5. Sure, let's do this in its own PR.