External link support

[merapi]

Numerous ways to do that, this one should do the job.

It was found in QA:
Finally, in the footer, there seems to be an error in clicking the "See the source code" link and there is no link to the Google Privacy Policy, T&S.

What T&S link should we use?

[dero]

@merapi I don't think this is a good solution – it's an ad hoc rule that's easy to be forgotten and it leads to unexpected behavior and confusion. A standard looking link should always behave like a standard link.

Instead we should be explicit about what is a standard link and what is a "custom link handled by the Router". Something like <a href="..." data-use-router>...</a> would work, because it would make it obvious some kind of router is used to extend its functionality.

[merapi]

@merapi I don't think this is a good solution – it's an ad hoc rule that's easy to be forgotten and it leads to unexpected behavior and confusion. A standard looking link should always behave like a standard link.

Instead we should be explicit about what is a standard link and what is a "custom link handled by the Router". Something like <a href="..." data-use-router>...</a> would work, because it would make it obvious some kind of router is used to extend its functionality.

2 nits:
A standard looking link should always behave like a standard link. - that's not the case for most of the FE routers that I saw (react/vue router etc.).
it's an ad hoc rule that's easy to be forgotten and it leads to unexpected behavior and confusion - you can say the same about data-use-router and because it's a SPA, it's more likely that you will encounter that confusion.

In case of SPA that condition should be flipped IMHO.
So that would mean adding an "external" attribute to those 2 links. How about that?

[dero]

that's not the case for most of the FE routers that I saw (react/vue router etc.).

@merapi Correct me if I'm wrong, but don't both routers use a custom element to define a router link in templates? We don't compile our templates, so I would be inclined to think our situation is different.

[merapi]

that's not the case for most of the FE routers that I saw (react/vue router etc.).

@merapi Correct me if I'm wrong, but don't both routers use a custom element to define a router link in templates? We don't compile our templates, so I would be inclined to think our situation is different.

That just depends on the context, and we didn't had the same.

[merapi]

Now with data-no-router solution.

[dero]

I maintain that custom routing should be opt-in when standard hyperlinks are used for navigation – not opt-out.

The <a href="URL"> element has a clear default action – to navigate to a given URL. The opt out approach is going to lead to situations where this experience is broken even for valid URLs simply by omitting the opt out attribute.

We may also not always be in control of the markup that is rendered – one can imagine video descriptions that are allowed to contain hyperlinks, it's a rather normal use case. In that situation we would need to add the opt out attribute on the fly. And if we did that, we wouldn't be able to serve an internal link this way. The system feels inherently unstable.

I've also re-checked the major front-end frameworks and their router implementation to verify that I'm not missing the mark here by requesting something unreasonable or illogical:

• React and Vue routers use a custom element.
• Angular router uses <a> with a custom attribute to define the route.
• Svelte SPA router uses <a> with a custom use:link attribute to invoke the router or alternatively a # preceding the route.

[derekherman]

I maintain that custom routing should be opt-in when standard hyperlinks are used for navigation – not opt-out.

I agree 100% and this should be fixed.

[merapi]

Updated with data-use-router approach, please re-check.

[dero]

LGTM, thanks.