custom directives on components: Can't access child component in directive hooks.

[zq8024]

Version

3.0.2

Reproduction link

https://codesandbox.io/s/weathered-resonance-d2f6t?file=/src/App.vue

Steps to reproduce

import { createApp } from "vue";

const App = {
    directives: {
        mydir: {
            mounted(el, binding, vnode, oldVnode) {
                console.log(vnode.component) //vnode.component should be CompB vue instance, but now is null
            }
        }
    },

    render() {
        return (<div>
            <CompB name='a1' v-mydir="1" />
        </div>)
    }
}

let CompB = {
    props: ['name'],
    render() {
        return (<div>{'test: '   this.name}</div>);
    }
}

createApp(App).mount('#app');

What is expected?

vnode.component should be the CompB vue instance

What is actually happening?

vnode.component is null

[LinusBorg]

the vnode represents the element, not the component.

The corrent way to access the component ìn Vue 3 is binding.instance

[zq8024]

the vnode represents the element, not the component.

The corrent way to access the component ìn Vue 3 is binding.instance

I want get CompB component instance in directive, but binding.instance is App component instance, how can i get CompB instance in directive?

[edison1105]

try getCurrentInstance

[zq8024]

try getCurrentInstance

getCurrentInstance is return null, not CompB instance

[LinusBorg]

I'll reopen this for now to explore this. This is a bit of an edge case where in Vue 2, vnode.context would have given you ComponentB indeed, as the vnode context gives you the instance that the elements belongs to.

binding.instance gives you the instance whose template contains the directive, and I'd think that for many typical custom directive situations, that the more desirable behavior.

The two are usually the same except when using a directive on a child component.

I wouldn't not consider this a bug as it is working as expected. We can either find a way to support the edge case or document this as a breaking change.

[zq8024]

I'll reopen this for now to explore this. This is a bit of an edge case where in Vue 2, vnode.context would have given you ComponentB indeed, as the vnode context gives you the instance that the elements belongs to.

binding.instance gives you the instance whose template contains the directive, and I'd think that for many typical custom directive situations, that the more desirable behavior.

The two are usually the same except when using a directive on a child component.

I wouldn't not consider this a bug as it is working as expected. We can either find a way to support the edge case or document this as a breaking change.

I think use binding.context is more suitable for this，because the current vnode is the actual dom element point to, not the ComponentB's vnode

[guogangj]

Is there any further news on this issue?

[cuiyajie]

I found binding.instance work normal in development, but it turned out to be VNode in production. I use vite for building.

[xsdream]

I found binding.instance work normal in development, but it turned out to be VNode in production. I use vite for building.

Finally solved? please

[matrunchyk]

I'm looking for this to resolve as well.

The two are usually the same except when using a directive on a child component.

That's exactly exception I ran into.

[tklkalok]

I am now facing the exact same situation that needs to access the child component's context (or called instance) in custom directives.

I found that for the mounted arguments ($el, $binding, $vnode, $prevVnode), $vnode.dirs[0].instance sometimes return the child component's context (or instance) and I can manipulate it but not always....

Back to the question itself, I am pretty sure that the child component's context (or instance) is needed to be included in custom directives in some of the use cases and that would be great if the Vue development team could consider adding it back in Vue 3. I'm still looking forward to a solution/workaround.

Cheers!

Vue Version: 3.2.33

[decademoon]

binding.instance gives you the instance whose template contains the directive, and I'd think that for many typical custom directive situations, that the more desirable behavior.

Really? What situations would you need the template component instance as opposed to the component instance the directive is applied to?

This is my use case:

const Autoselect = {
  mounted(el, binding, vnode) {
    // If the directive is applied to a component and that component has
    // an exposed select method, call that, otherwise call select on the DOM element
    if (typeof vnode.componentInstance?.select === 'function') {
      vnode.componentInstance.select();
    } else {
      el.select();
    }
  },
};

Some components have special logic for selecting its text contents. Is there no way to do this?

[decademoon]

I figured out I can do vnode.ctx.exposed.select() but that's delving into private APIs which isn't ideal.

[eric-gitta-moore]

I figured out I can do vnode.ctx.exposed.select() but that's delving into private APIs which isn't ideal.

I'm also exploring similar things, but unfortunately, vnode.component cannot directly obtain the instance of the bound component. Instead, you can get vnode.ctx.proxy.

vnode.ctx.exposed.select() vs vnode.ctx.exposeProxy.select()

For me, I need to call the component to define functions through defineExpose, but I found there are two things named "expose" or something similar. What's the difference between these two?

[arcs-]

I figured out I can do vnode.ctx.exposed.select() but that's delving into private APIs which isn't ideal.

I'm also exploring similar things, but unfortunately, vnode.component cannot directly obtain the instance of the bound component. Instead, you can get vnode.ctx.proxy.

vnode.ctx.exposed.select() vs vnode.ctx.exposeProxy.select()

For me, I need to call the component to define functions through defineExpose, but I found there are two things named "expose" or something similar. What's the difference between these two?

I have a similar issue, however, while this works in a dev environment we don't get the exposed functions in a build

[eric-gitta-moore]

I figured out I can do vnode.ctx.exposed.select() but that's delving into private APIs which isn't ideal.

I'm also exploring similar things, but unfortunately, vnode.component cannot directly obtain the instance of the bound component. Instead, you can get vnode.ctx.proxy. vnode.ctx.exposed.select() vs vnode.ctx.exposeProxy.select() For me, I need to call the component to define functions through defineExpose, but I found there are two things named "expose" or something similar. What's the difference between these two?

I have a similar issue, however, while this works in a dev environment we don't get the exposed functions in a build

I'm sorry that I gave up using custom directives. I believe this is not the functionality I need. The desired feature should be more similar to HOC in React. I just hope that whenever data is passed to the child component, I have the ability to intercept and modify it.