Feature request: enable some way of handling external links by router.

[bmacnaughton]

I have read a number of discussions on this and think it's worthwhile to raise this as an enhancement.

The following esults in each element rendering as an <li> with appropriate list styling but acting like a link. The problem is that if one of the links is to an external site it fails.

<template>
  <nav class="navs">
    <ul class="nav">
      <!-- -->
      <router-link
        class="nav__item nav__link"
        tag="li"
        active-class="-active"
        :to="nav.link"
        :key="nav.name"
        exact
        v-for="nav in navs">
        {{ nav.name }}
      </router-link>
    </ul>
  </nav>
</template>

It's possible to convolute the logic with something like the following. It requires directly inserting the <a> elements but works given minor changes to CSS or always inserting links inside <li> elements (even though if there are no external links it can be coded using <router-link tag="li" ...>).

<ul>
  <li v-for="nav in navs">
    <a v-if="nav.external" class="nav__item nav__link" :href="nav.link">{{ nav.name }}</a>
    <router-link v-else
      class="nav__item nav__link"
      active-class="-active"
      :to="nav.link"
      :key="nav.name"
      exact
    >{{ nav.name }}</router-link>
  </li>
</ul>

I previously tried just inserting external URLs into the <router-link> elements and handling them in router.beforeEach(). It's possible to apply some heuristic checks to see if the URL is external and set window.location.href if it is. But the problem I ran into then is that using the browser back button always resulted in an error because the history is stored as localhost:8080/http:/google.com (when testing with "http://google.com" as the external link).

It seems that that programmatically building lists of links is a common problem and that there should be a straightforward solution. Two solutions that would help me are 1) allowing the "external" prop on <router-link> elements that correctly stores history so the back button works or 2) provide some way in router.beforeEach() to prevent storing the unusable history entry. I think the first, or some variation where the externality of a link specified in the element, is the most straightforward.

I guess another solution is a strong recommendation in documentation on how to handle this seemingly common situation.

Thanks for considering it.

[lbineau]

Same problem here to handle 301 redirection.

[LinusBorg]

What does 301 redirection have to do with <router-link>?

[ydnar]

Hi, relatively new Vue user here. We’re porting an existing React app to Vue using Nuxt and got tripped up on this: nuxt/nuxt#770

Our existing app uses react-router and Express middleware to handle a number of legacy URLs, some of which redirect internally, and some of which redirect to external (absolute) URLs.

Digging through the source code of vue-router and nuxt, it looks like the issue is split between the two. Nuxt mangles URLs on the server side (before setting a Location header), and vue-router mangles URLs on the client side (before sending to HTML5 history).

It looks like the Nuxt folks are interested in handling this on their side (which would affect the server implementation). I’d love to see this handled in vue-router for the client side.

[htfy96]

+1 here. It is quite common to implement dashboard of management system as a SPA while rendering pages in frontend in traditional way with Vue.js just as a convenient template engine. In this case, <navbar> problem described by OP could be annoying.

[luxaritas]

I'd like to see this in the configuration of a Router instance, so that I can have a named route pointing to an external site. In particular, I would like this since I am replacing an existing site, redirecting unimplemented pages to the original site, and this would prevent having to update every anchor tag with a the router-link once the page is implemented.

[allanberry]

Indeed. The CMS for which I'm building a frontend has no distinction between internal or external links: it just stores the URL in a text field. This forces me to simply use <a> tags in places where I'd rather use <router-link>, because the template logic otherwise gets quite convoluted.

So, router links should ideally, with the same tag signature, handle:

• absolute urls, either local or to an external host
• relative urls, both that Vue-Router knows about, and also urls to pass through (for handling by the server)

[rodet]

I second this. Given a router definition, it would be pretty standard to programmatically check the link host against the window location. It's not that hard to implement manually, but requests mangling a bit with the tooling and lifecycle (first creating links to test, then replacing them by router-links). Would be better if avoidable.

[balint42]

Here is how this currently can be handled:

<component :is="el(item.href)" :to="item.href" :href="item.href" class="item"> </component>
where
el(url) { return _.startsWith(url, 'http') ? 'a' : 'router-link'; },
The test in el can of course be improved.