vue-router icon indicating copy to clipboard operation
vue-router copied to clipboard

beforeRouteUpdate never calls next callback

Open bdoms opened this issue 7 years ago • 17 comments

Version

2.7.0

Reproduction link

http://jsfiddle.net/znmLks2w/2/

Steps to reproduce

Create a component with a beforeRouteUpdate guard that passes a callback to the next function.

What is expected?

The callback function should be called.

What is actually happening?

The callback is never called.


In my example I have both beforeRouteEnter and beforeRouteUpdate pointing to the exact same function. beforeRouteEnter works exactly like I expect, but beforeRouteUpdate does not. Click on the links to try to add one to the displayed value and you'll notice it works the first time but never any of the subsequent times.

If this behavior is purposeful then I would consider it a documentation bug - the docs need to be absolutely clear that next behaves differently depending on where you're calling it from. But even as I type this I'm realizing that if that's the case then it's terrible design. It should work the same way regardless.

bdoms avatar Jul 10 '17 22:07 bdoms

The difference between both hooks is that enter doesn't have access to this so it needs the callback, while update has access to this. But I agree it should be more consistent, it's quite usual to have the same function in both hooks.

posva avatar Jul 11 '17 07:07 posva

I'd say that this is a bug, not an improvement. Consider when using <router-view :key="...">, it becomes impossible to access the new component, so you can't inject data. See: http://jsfiddle.net/thatguystone/nypp9jma/1/

thatguystone avatar Jul 15 '17 06:07 thatguystone

I've just step on this problem. Could it be explained in the documentation on the navigation-guards page ?

amertum avatar Aug 02 '17 13:08 amertum

Just discovered this problem.

arnabrahman avatar Aug 06 '17 06:08 arnabrahman

Also observing this problem

justin-hackin avatar Aug 19 '17 22:08 justin-hackin

I understand your confusion, but if you look at the documentation closesly, it states that passing a callback to next() is only necessary (and supported) in beforeRouteEnter, because we can't access this in that hook.

Both beforeRouteUpdate and beforeRouteLeave do have access to this, so the callback is unnecessary and therefore not supported.

Solution: just use this.yourdataProp = 'yourvalue' to change data.

I will see if I can come up with a quick PR for the docs to stress this difference as this has come up a couple of times already.

LinusBorg avatar Aug 25 '17 19:08 LinusBorg

While updating the docs may help a few people who pay close attention understand what's happening better, it does not actually solve the problem, which is that developers expect a framework like Vue to provide a consistent interface. Just because the callback is unnecessary in some cases is not a good reason to make the same function behave differently depending on where it's called from. With two varying implementations that any reasonable person would expect to do the same thing, it means that the confusion is going to persist even if it's spelled out clearly in the docs. Plus, it also means that every developer who runs into this has to re-invent the wheel and figure out a way to detect and handle this situation.

Let me illustrate. Given this setup:

component1 = {
    beforeRouteEnter: myFunction
}
component2 = {
    beforeRouteUpdate: myFunction
}

What seems more intuitive, natural, and easy for developers? This:

myFunction = function(from, to, next) {
    // somehow detect which hook called this function
    if (calledByEnter) {
        next(myCallback)
    }
    else {
         next()
         myCallback(this)
    }
}

Or this:

myFunction = function(from, to, next) {
    next(myCallback)
}

The situation currently requires the former. I think the people commenting in this thread - and the project as a whole - would benefit from the latter.

bdoms avatar Aug 25 '17 20:08 bdoms

You might have a point there, I'll reopen #1676 for further discussion, because that ticket was apprearantly requesting that change as well and is newer.

LinusBorg avatar Aug 25 '17 20:08 LinusBorg

@LinusBorg what's the difference? I really see the same FR in both issues

posva avatar Aug 25 '17 22:08 posva

No difference, really. I just feel that bdoms has made a good case that should at least be discussed. I'm not convinced yet if offering a callback for all in-component hooks is actually optimal either, but it's worth to think about so I wanted to have an issue open about it, I dont really care which.

We can also reopen this and I'll close the dupe again.

LinusBorg avatar Aug 25 '17 22:08 LinusBorg

Ah, I see what happened 😆 This one is still opened. I personally think this is worth adding. It's convenient to pass the same function to both hooks. I'll close the other one

posva avatar Aug 25 '17 23:08 posva

Oh... it's realy time for bed for me.

LinusBorg avatar Aug 25 '17 23:08 LinusBorg

I don't understand how you are supposed to get this to work. I have updated the fiddle to change x value on beforeRouteUpdate. On update, you don't have access to this as far as I was able to do. Please, could you explain how to make this work ? My guess is some .bind(this) might be necessary or something. This is so frustrating, I tried a lot of things and nothing is working so far...

lionel-bijaoui avatar Dec 04 '17 10:12 lionel-bijaoui

What solution are you guys using now? I had to dupe my code to do same thing in both beforeRouteEnter + beforeRouteUpdate

jimmywarting avatar Jul 21 '18 19:07 jimmywarting

What solution are you guys using now? I had to dupe my code to do same thing in both beforeRouteEnter + beforeRouteUpdate

Actually I'm doing the same, duplicating code in Enter and Update, I could create a global function and call it changing the target (this or vm), or somebody found another more elegant solution?

dariodepaolis avatar Apr 04 '19 09:04 dariodepaolis

@dariodepaolis i'm not sure it's the "best pattern" but I faced this and solved it by a mixin :

export default f => ({
  beforeRouteEnter: f, beforeRouteUpdate: f
})

which i use in most cases like this :

import beforeRoute from '@/mixins/beforeRoute
import store from '@/store'

export default {
  mixins: [beforeRoute(
    (to, from, next) => store.dispatch('item/fetch', to.params.id)
      .then(() => next())
      .catch(() => next('/404'))
  )],

  computed: {
    ...mapState({
      item(state) { return state.articles[this.$route.params.id] }
    })
  }
}

(but i don't require access to this)


I do understand the major difference between beforeRouteEnter and beforeRouteUpdate, but i somehow wished for a beforeRoute instead, either in the router routes or component. (the one in the routes is only called when the route is reached from the browser i believe, so navigating to it wouldn't trigger the guard)

What's mainly counter-intuitive is that while beforeRouteEnter is defined in the component, it is not really a method of the component since it's called before the component is created...

y-nk avatar May 14 '19 14:05 y-nk

I'd say that this is a bug, not an improvement. Consider when using <router-view :key="...">, it becomes impossible to access the new component, so you can't inject data. See: http://jsfiddle.net/thatguystone/nypp9jma/1/

This is got me. You really don't have access to the next component.

I resolved to fetching data in beforeRouteUpdate saving to store and then using created to get the value from store.

Update created is called asynchronously. To this point, beforeRouteUpdate and beforeRouteEnter have proved not useful due to the limitation on beforeRouteUpdate

omushpapa avatar Oct 29 '20 10:10 omushpapa