Routing guard for parameter changes

[mitar]

What problem does this feature solve?

I am trying to implement TodoMVC with Vue router for practice. I have defined the following route:

{
  path: '/:visibility?',
  name: 'todos-display',
  component: Vue.component('todos-display'),
  props: true,
  beforeEnter: (to, from, next) => {
    if (!to.params.visibility || ['all', 'active', 'completed'].includes(to.params.visibility)) {
      next();
    }
    else {
     next('/');
    }
  },
}

And in the todos-display component I have the following prop defined:

props: {
  visibility: {
    type: String,
    default: 'all',
    validator: (value) => {
      return ['all', 'active', 'completed'].includes(value);
    },
  },
}

The goal of this is that the component should not care about routing or use routing information, or try to resolve invalid parameters. It should be used correctly and with only given values. On the other hand, I want router to assure that only correct values are sent down to the component. I have defined beforeEnter which works well for initial URL, but because visibility is a parameter, it is not run when parameters change, so when parameter changes, the component gets invalid value.

What does the proposed API look like?

I would suggest to add beforeRouteUpdate hook to routes which would be called before parameters change and allow checking for their values in the place which should contain this logic (the route) and not in the component (which should just know about props).

beforeRouteUpdate would otherwise behave identically to beforeEnter in arguments and semantics.

[LinusBorg]

That hook already exists - with exactly that name and functionality. please re-read the chapter about guards in the documentation

[mitar]

No it does not! It exists on the component, and not on the route! I described why I would prefer logic separation between components and routes. The whole point of using props is so that component should not have know about routes. But without beforeRouteUpdate on routes this is not really doable.

[mitar]

(Alternative is to use $watch, but again it is unclear how to use it on route and not component.)

[LinusBorg]

Sorry, misunderstood your request. Reopened now.

[mitar]

Thanks! I will update text above to make it clearer.

[posva]

As for beforeRouteLeave (#1195), beforeRouteUpdate have access to this, that's why they can only be declared on a component. I personally think that you should add the beforeEnter hook to the component as well for multiple reasons:

• Benefit from code splitting
• Keep view specific guards in the view

beforeEnter on routes allows you to have generic guards that do not depend on the component while component guards are specific

About your problem, I'd suggest using a computed property to coerce the value of the prop (https://vuejs.org/v2/guide/migration.html#coerce-Prop-Option-removed)
Or to use a HOC to wrap the view and always provide a valid prop
edit: Or use the props option: https://router.vuejs.org/en/essentials/passing-props.html. There's also a PR by blake to make that better

Even though I'm against this FR, I'll add it to #1195 and close this one as a dup

[mitar]

I do not think I would need access to this for what I need in route's beforeRouteUpdate. This could be a difference between route's beforeRouteUpdate and component's beforeRouteUpdate.

Keep view specific guards in the view

Those are not view specific guard. View specific guard is in the validation of the prop. But how that component is called and how to assure that the prop gets the correct value should be done by router. I think then this cleanly match why you can use a prop for passing route information.

For example, how can I test this? If I have a clean split as I recommend, then:

• if prop is correct, component will render
• if prop is incorrect, component will fail on validation

You propose:

• if prop is correct, component will render
• if prop is incorrect, component will change the route

This does not feel like a good separation.

I'd suggest using a computed property to coerce the value of the prop

But that will not change the URL. I do not have an issue that prop is invalid value. I can handle that both with coercing or validation. I would like to keep URL to match the state of the app. So if URL is invalid, I should not fix state only internally, but I should also change URL to expose that fixed (coerced) internal state.

Or use the props option: https://router.vuejs.org/en/essentials/passing-props.html.

That is exactly what I am doing! This is why I have this problem. I am passing props option from route to the component. I would like to keep this separation which props allows clean. But I currently cannot because there is no way to handle properly what to do with invalid values of props at the route level.

[posva]

It's not about not needing access to this but about being consistent

how to assure that the prop gets the correct value should be done by router

I disagree on that because a prop is specific to a view

You can handle incorrect values in beforeRouteEnter and beforeRouteUpdate but you simply don't like it...

[mitar]

But it is even written in documentation:

Using $route in your component creates a tight coupling with the route which limits the flexibility of the component as it can only be used on certain urls.

If I put resolving of where to redirect on bad props into a view, I cannot use the same view in multiple locations. But if it is in route, then I can do that easily.

[posva]

It doesn't mean you must avoid it at all cost.
If you want to decouple the view from the router, for whatever reason you choose to, you can use a HOC to connect your view to the router by making the HOC responsible for handling that

[econic]

I find this feature request quite useful for my current scenario:

/posts fetches a list of posts in route's beforeEnter config
/posts/:id/attachments fetches the attachments in route's beforeEnter config

when switching directly between two posts' attachments, the attachments of the new post won't be fetched.
Therefore a route perfect route config would be one that fetches the post's attachments on routeEnter and all subsequent route updates where :id changes.
How's that supposed to work currently if i want to keep data fetching out of the components?

Just like @mitar i wouldn't need the component reference in the route's beforeUpdate config.