Status Quo

In vue-router, the URL is the single source of truth. That means that no matter weither the user triggers a route from an external link, by typing out the URL himself or by clicking on a <router-link> inside our app, the same route if the URL is the same, then the same routes will be matched, and the same components will be rendered - no side-effects are taken into account.

I consider this to be a sensible, good approach. But there are situations where this behaviour is undesired:

The problem

If you go to Twitter's website, and open a tweet from any place (your own timeline, someone else's timeline, a list ...), three things happen:

1. A modal with the tweet opens
2. the URL changes to an absolute URL pointing to that tweet
3. Something doesn't change, though: the background of the modal. Even though we started from e.g. twitter.com/linus_borg and went to twitter.com/vuejs/status/xxxxx when we opened the modal, my profile's timeline is still in the brackground.

The user could simply copy & paste the tweets URL, post it somewhere, go back to twitter, close the modal and continue browsing my profile. Great!

Butr currently, this is not possible with vue-router. With vue-router, we would either have to

• render the modal as a child-route of my timeline, which means the URL would not point to the tweet really, but to /linus_borg_/status/vuejs/status/... or something.
• render the tweet route as an absolute path, but then the background view (my profile) would be destroyed.

Downsides

This breaks vue-routers philsophy of the URL as the only source of truth, because opening a tweet from timeline leads to a different view than opening the tweet's URL directly.

Proposed Solution(s)

Here this proposal becomes thin, and I didn't add the discussion label for nothing:

I don't really have an idea on how to approach this. I know that it's probably very hard to implement this in vue-router as it working different to the whole route-matching pattern etc, so I'm open to ideas.

Maybe, we could at least implement a way to "pause" the router's URL change callback? So the user can "deactivate" the router momentarily, change the URL himself, show the modal, and on closing the modal, reactivate the router?

Or maybe this could be accomplished with named router views, if we allow route that only point to a named view , so the "normal components, e.g. the profile, stay rendered, and we show the overlay in a named view? (tested this, doesn't work right now).

Anyways, I think this wold be a great feature for many scenarios (Spotify's uses this for its ovelays showing album / playlist / artist views anywhere, for example)

So, what do you guys think? Any opinions? Ideas for solutions?

在开发微信中使用的页面的时候，使用微信的jssdk功能，发现一点问题

在hash模式下，wx.config()可以正常工作，但在history模式下，安卓手机中无法正常config，会提示invalid signature的错误，IOS下则是正常的，非常困扰。查了微信的文档说安卓手机可能是pushState引起的。

@everyone give me some help...

I have a router-view that needs to be reloaded after sending some POST requests and receiving whether the operation was successful, but

this.$route.router.go(this.$route.path)

doesn't trigger a reload even if the component's route.canReuse is set to false.

Now I can only do

created.apply(this) // `created` is the life-cycle hook function for the component

in the ajax callback to force the router-view to update itself, which is cumbersome.

Perhaps something like $route.router.reload() would be great, as it would be the counterpart of location.reload().

I am building a large scale application with "mini applications" hosted within the application. Each mini application is being developed by another team. I would like to dynamically add nested child routes to an existing route to allow dynamic registration of each of the mini apps.

for example:

const routes = [
        {path: 'a', component: ComponentA, name: 'a'},
        {path: 'b', component: ComponentB, name: 'b'},
];

//MiniApp.js
export default Vue.extend({
    beforeCreate () {
        this.$router.addChildRoutes(this.$router.currentRoute.path, routes);
    },
    template: `
<div>
  <div class="page-host">
  <router-link to="{name: 'a'}">a</router-link>
  <router-link to="{name: 'b'}">b</router-link>
  <transition name="fade" mode="out-in">
    <keep-alive><router-view class="view"></router-view></keep-alive>
  </transition>
  </div>
</div>`,
});

//The app itself
Vue.use(Router);
import MiniApp from "./MiniApp";

const config = {
    linkActiveClass: 'active',
    scrollBehavior: () => ({x: 0, y: 0}),
    routes: [
        {path: '/mini', component: MiniApp, name: 'mini'}},
    ]
};
let router = new Router(config);
const vue = new Vue({
   router,
   template: `
<div>
  <div class="page-host">
  <router-link to="/mini">a</router-link>
  <transition name="fade" mode="out-in">
    <keep-alive><router-view class="view"></router-view></keep-alive>
  </transition>
  </div>
</div>`,
}).$mount('#app');

Since components are already taking care of not polluting other places, I believe it would be really nice to have components declare their own routes (subroutes actually) in their own space. This would really help for huge apps and it would favor components reusability. I was thinking of a 'routes' object in the component's definition object but this could be in a vue file as well.

I write it in this case, but it is wrong. http://router.vuejs.org/en/essentials/getting-started.html

"vue": "^2.0.1",
"vue-router": "^2.0.0",
"vuex": "^2.0.0"

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Document</title>
</head>
<body>
<div id="app">
  <h1>Hello App!</h1>
  <p>
    <!-- use router-link component for navigation. -->
    <!-- specify the link by passing the `to` prop. -->
    <!-- <router-link> will be rendered as an `<a>` tag by default -->
    <router-link to="/foo">Go to Foo</router-link>
    <router-link to="/bar">Go to Bar</router-link>
  </p>
  <!-- route outlet -->
  <!-- component matched by the route will render here -->
  <router-view></router-view>
</div>
</body>
</html>

import Vue from 'vue'
import VueRouter from 'vue-router'

Vue.use(VueRouter)
// 0. If using a module system, call Vue.use(VueRouter)

// 1. Define route components.
// These can be imported from other files
const Foo = { template: '<div>foo</div>' }
const Bar = { template: '<div>bar</div>' }

// 2. Define some routes
// Each route should map to a component. The "component" can
// either be an actual component constructor created via
// Vue.extend(), or just a component options object.
// We'll talk about nested routes later.
const routes = [
  { path: '/foo', component: Foo },
  { path: '/bar', component: Bar }
]

// 3. Create the router instance and pass the `routes` option
// You can pass in additional options here, but let's
// keep it simple for now.
const router = new VueRouter({
  routes // short for routes: routes
})

// 4. Create and mount the root instance.
// Make sure to inject the router with the router option to make the
// whole app router-aware.
const app = new Vue({
  router
}).$mount('#app')

// Now the app has started!

open url http://localhost:3000/admin/#/bar

Version

3.1.1

Reproduction link

https://jsfiddle.net/Lom7hxn5/

Steps to reproduce

1. Call $router.replace or $router.push twice with same path

What is expected?

Error object provides stacktrace (stack property)

What is actually happening?

No stack trace in the error object

When NavigationDuplicated error is thrown, there is no stack trace in the error itself so when error is reported through error reporting service like Sentry, there is absolutely no context to go with the error and so it's hard to figure out where that error originated.

Transpiled code for the NavigationDuplicated class looks like this: https://github.com/vuejs/vue-router/blob/5141def3a21da479c2858c0d70db3cb438c3b7d0/dist/vue-router.common.js#L1935-L1946

which is problematic because instantiating such function won't create a stacktrace. It would work fine with non-transpiled code (although I'm not suggesting to not transpile it): https://github.com/vuejs/vue-router/blob/44c63a963f05ede229d8658a45b2388e244ce00b/src/history/errors.js#L1

One possible solution would be to manually set stack trace with:

this.stack = (new Error()).stack;

but I'm not sure how that would be done if transpilation is done by webpack/babel...

There is also one extra bug in that code. The line that instantiates error passes a route object to the error: https://github.com/vuejs/vue-router/blob/fc42d9cf8e1d381b885c9af37003198dce6f1161/src/history/base.js#L125 but error doesn't do anything with it: https://github.com/vuejs/vue-router/blob/44c63a963f05ede229d8658a45b2388e244ce00b/src/history/errors.js#L2

Saving route properties on the error object would also help in deciphering source of the error.

What problem does this feature solve?

I'm developing a Quasar app where I have, for example, the following route structure:

const router = new VueRouter({
  routes: [
    {
      path: '/clients',
      component: Clients,
      children: [
        {
          path: ':id',
          component: Client,
          children: [
            {
              path: 'visits',
              component: ClientVisits
            }
          ]
        }
      ]
    }
  ]
})

In all three routes I have a beforeRouteEnter guard that fetches data from an API and stores that data in a Vuex instance. Furthermore, ClientVisits uses the data that was fetched and stored in Client.

In terms of UI design, though, I do not want ClientVisits to be shown as a nested child view; it needs to be at the top level. If you know Android development, ClientVisits should work as an Activity and not a Fragment.

What does the proposed API look like?

Perhaps if Client had no <router-view> in its template, children would then be mounted at root level?

It looks like the click event on the <router-link> is handled before any custom click events:

<router-link to="/b" @click.native.prevent="clicked">should NOT route to b</router-link>

const app = new Vue({
  router,
  methods: {
  	clicked: function(e) {
        // Does not prevent route change
    	e.preventDefault()
    }
  }
  
})

See working fiddle: https://jsfiddle.net/floorish/zhyqgqpz/ The <router-link> component checks e.defaultPrevented here : https://github.com/vuejs/vue-router/blob/dev/src/components/link.js#L49 , but that is still false when it checks the condition.

Only workaround I've found is to capture the event on a parent element (included in fiddle).

Vue version: 2.0.7 Vue-router version: 2.0.2 Possibly related to: https://github.com/vuejs/vue-router/issues/390

Version

2.7.0

Reproduction link

https://codepen.io/Juli0GT/pen/veEEpr

Steps to reproduce

Before reloading page thats my $route component:

$route:Object fullPath:"/dashboard/customer-service?subnav=dashboard&activeClass=active" meta:Object (empty) name:“csDashboard" params:Object (empty) path:”/dashboard/customer-service" query:Object

What is expected?

Having same $route component after reload

What is actually happening?

If I refresh the page my router doesn’t recognise anymore my route, and my $route object looks like this:

$route:Object fullPath:"/“ meta:Object (empty) params:Object (empty) path:”/" query:Object (empty)

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.

Version

3.6.5

Reproduction link

stackblitz.com

Steps to reproduce

1. Giving a basic options API component

   <!-- using options API -->
   <template>
      <div>{{ msg }}</div>
   </template>
   
   <script>
   export default {
     computed: {
         msg() {
            return `My route name is ${this.$route.name}`;
         }
     }
   };
   </script>
   

2. refactoring to composition api

   <!-- Refactoring using composition-api -->
   <script>
   import { useRoute } from 'vue-router/composables';
   import { computed } from 'vue';
   
   export default {
     setup() {
       const $route = useRoute();
       const msg = computed(() => {
         `My route name is ${$route.name}`;
       });
   
       return {
         msg,
       };
     },
   };
   </script>
   

3. The test that worked before, now breaks.

   import { mount } from '@vue/test-utils';
   import SomeComponent from './SomeComponent.vue';
   
   const $route = {
     path: '/some/path',
   };
   
   function Wrapper() {
     return mount(SomeComponent, {
       mocks: {
         $route,
       },
     });
   }
   
   test('mount component',  () => {
     const wrapper = Wrapper();
   
     expect(wrapper.exists()).toBe(true);
     // TypeError: Cannot read properties of undefined (reading 'currentRoute')
   });
   

What is expected?

using options/composition-api should not affect the test suite output

What is actually happening?

Using options/composition-api requires different ways to test (mock)

Additional Comments

Link to reproduction with same component written in "options API" mode https://stackblitz.com/edit/vitejs-vite-rdjvxj?file=src%2Fviews%2FAbout.test.js

Heya! 👋 While I was waiting for the 3.6.x release, I rolled some in-house vue-router hooks as per https://github.com/vuejs/vue-router/issues/3760#issuecomment-1191774443. This allowed refactoring some options-API components to composition-api "mode" while keeping my test suite intact.

I thought the refactor to use the official package hooks would be a simple find/replace but my test suite broke. After some digging, the reason is that the hooks implementation relies on router.currentRoute property and afterEach hook, which made the tests using the simplest $route mock as suggested in vue-test-utils docs to fail.

Of course there's several ways to fix it: updating the test mocks as below; setting up a router with localVue as per docs; stubbing modules jest.mock(); etc;

import { mount } from '@vue/test-utils';
import SomeComponent from './SomeComponent.vue';

const $route = {
  path: '/some/path',
};

function Wrapper() {
  return mount(SomeComponent, {
    mocks: {
-      $route,
+      $router: { currentRoute: $route, afterEach: vitest.fn() },
    },
  });
}

Question

If you went this way^1, I'm sure there are good reasons for it. I'm just curious on why didn't you go with a similar approach as vue-router@4, as in, with a reactive object derived from getCurrentInstance().proxy.$route as per^2 which kept tests working without any change — but surely break some other stuff.

Cheers and thanks for your work on the router! Feel free to close this if you think it's related with @vue/test-utils docs instead ✌️

What problem does this feature solve?

being able to return a value in a navigaiton guard:

router.beforeEach(to => {
  if (!user)
  return { name: 'login', query: { redirectTo: to.fullPath } }
})

### What does the proposed API look like?
Like v4. X

<!-- generated by vue-issues. DO NOT REMOVE -->

What problem does this feature solve?

The matcher implementation always use path-to-regex lib. It is too much for static paths, where it is possible to just compare strings.

Also, the implementatioin is O(N), if you have 100 routes and want to match the last one (that is static), you run 100 regex tests. Regex is around ~10x slower than a simple string match and with a lookup table it is O(1).

https://github.com/vuejs/vue-router/blob/5d7afbe25f6b212bd4adb8344da72f6227a5c6d2/src/create-matcher.js#L85-L89

What does the proposed API look like?

The API don't change, it is just optimization.

I did a draft PR #3707 to show the idea.

This is a draft implementation with some new ideas.

• Static paths don't need regex match for most cases.
• Match don't have to be always linear, it is possible to match only with static paths.

Regex match is 10x slower than simple object access. I still have to run some dynamic matches to not break ordering compatibility.

I still want to integrate it better with current code, I did this implementation to validate the issue and run some benchmarks.