Rewriting URLs

[ClassicOldSong]

What problem does this feature solve?

Much like redirect, but a programmable alias route. Such as when I'm visiting '/me', actually I'm visiting '/user/:username'.

What does the proposed API look like?

{
path: '/alias',
aliasTo: to => 'path/I/would/like/to/be/aliased/to'
}

[posva]

After thinking about it, I think it's a good idea to have something like this. Having alias and aliasTo can be confusing though. It could also be just alias with no component option but I still think it's confusing:

{ path: '/me', alias: '/users/posva' }

Maybe something called replace instead

[ClassicOldSong]

Maybe rewrite could be better?

[mattbryanswan]

rewrite is exactly right, I think. This appears to fit my use case as well. For example, I need a detail page for events, so the no-brainer url looks like this:

/event/:id

However, that'll be a little ugly. Ideally, I want it to be something more like this:

/event/name-of-event

Currently, I cannot do this using aliases unless I explicitly create every route and every alias. Having dynamic aliases to be able to connect :key to :id would be fantastic.

[SerikDM]

Please check if this solution works for you:
https://github.com/SerikDM/vue-router

description:
add '*' route, in 'beforeEnter' handler find out what route you want to redirect to, pass object with 'ninjaPath'(=to.path) property to 'next()'
i.e.:
next({ path : '/user/123', ninjaPath : '/user/me' })

[brophdawg11]

This would be an awesome addition and I think would solve the use-case I'm working with now. Our e-commerce app has a "catch-all" /:slug route that serves a few different types of pages (i.e., /dresses generates a tiled view of products in the dresses category whereas /fall-fashion may lead to a CMS-driven page of content regarding fall fashions. This is all driven by route.params.slug and we look up what type of page it should be.

Our homepage is just a CMS-driven route for the slug homepage, so /homepage is the same as what we want rendered for /. I thought the following would do the trick but it doesn't seem like it actually populates the proper route.params.slug field as I had hoped it would when going to /:

route = [{
    path: '/homepage',
    alias: '/',
    component: CatchAll,
}, {
    path: '/:slug',
    component: CatchAll,
)];

I did look briefly into using the props behavior but I don't think it would work in our SSR scenario where we run fetchData/asyncData prior to instantiating the component so we don't have access to those prop values?

[posva]

Thank you for this but after some thought, I don't think this is the right way to go. So far the only problem proposed seems to be slugs. There are different solutions for that scenario like including the id as part as the param (this is mainly for SEO purposes). Another solution is using a navigation guard to ensure the slug is correct, store the association of the slug to the data somewhere and use that:

router.beforeEach((to, from, next) => {
  if (to.name !== 'slug') return next()
  let { slug } = to.params
  fetchDataFromSlug(slug)
    .then(data => {
      storeSlugData(slug, data)
      next()
    })
    .catch(err => {
      if (err.status === 404) next({ name: 'not-found' })
      else next({ name: 'error' })
    })
})

If you think this is still worth pursuing, you should go through the process of an RFC: vuejs/rfcs#122