Composition-api: Data passed to Component from beforeRouteEnter not initially available

[ggedde]

When passing data back to the component from beforeRouteEnter like this:

beforeRouteEnter(to, from, next) {

    // Do Stuff Here

    next(vm => {
        vm.foo = 'bar';
    });
}

foo is not available in the Setup() method without adding it to the return{}.
I understand why I need wait for nextTick to access it, but not sure why it has to be declared in the return{}.

Is this is a requirement by design or a bug?

This seems like a bug or just out of scope for this plugin which is fine if so or is this a bug with VueRouter and needs to be addressed within VueRouter?

Thanks

[LinusBorg]

It's just a result of the current Vue 2.0 & VueRouter architecture and lifecycle, which, in this specific case, doesn't work well with the new composition API as it wasn't designed with it in mind.

So it's not a bug. as to why you have to return it from setup to have access to it:

The beforeRouteEnter callback is run when the component has already been initialized, that means setup(), data() and created() have already been called. In the "old days" the property to which you assign with, vm.foo would have been initialized in data, right?

So now with the composition API, you have to initialize the property/ref in setup:

setup() {
  return {
    foo: ref(null)
  }
}

Now there's a reactive property called foo which the beforeRouteEnter hook can access.

Just for reference this is how you could use a watch to actually wait for a value being set instead of relying on the nextTick as a "workaround":

setup() {
  const foo = ref(null)
  const unwatchFoo = watch(foo, fooValue => {
    doSomething(fooValue)

    // if you want this to run only once: 
    unwatchFoo()
  }, {lazy: true })

  return {
    foo,
  }
}

[ggedde]

Thanks LinusBorg, this makes sense and i appreciate the full description and examples.

However, from a purely dev workflow perspective it seems odd that one would have to return something that is only needed within a function and is not needed in the template. I hope this gets looked at in the final release.

[LinusBorg]

However, from a purely dev workflow perspective it seems odd that one would have to return something that is only needed within a function and is not needed in the template.

Can you follow the comparison I have done with data?

With the normal options API you would do this:

data() {
  return {
    foo: null,
  }
}

which does pretty much exactly the same...

[ggedde]

@LinusBorg Yes,
What I meant was that in the normal Options API your variable only needed to be defined once (in the return of data()). Which allowed you to access it within the methods and within the Template, but for the Composition API to use them within a function you need to have them defined in the return{} and also within the setup() as a variable. So if you have let's say 10-20 variables that need to be accessed within the functions then you will end up with what looks to be like redundant code. Although, you could just use one reactive element which wouldn't need you to update the return variable, but then you end up with a lot of dot notation in your templates. This is merely just an observation.