Introduce inheritDirectives: false

[renatodeleao]

Curious to check the community pulse on this, since I do not have enough knowledge of @vue core code to understand the implications of such an idea or even if it's feasible so bear with me, please.

---

One thing that broke a lot of my tests while migrating to vue@3 was that I relied upon heavily — almost 100% — on a v-test="'some-id'" directive to target my elements and components. The only thing this directive does is conditionally add data-test-id attribute when !production.

With the vue@2 single root node limitation, directives declared on the components always "found a way to fall through" into the root element. With vue@3 that's no longer the case and directives are ignored if the multi-root node or if root node does not render an element (directly). For the first scenario, it makes total sense, vue could not simply guess which element I wanted. In the second scenario, there is a nuance: I can still render a single node element, but not directly. Some of my components have renderless/provider wrappers as the root element and the actual element node is passed to its slot. In those scenarios the directive declared on the component would still fallthrough correctly in vue@2 and now it doesn't.

Example

<!-- VDialog.vue -->
<template>
  <!-- renderless accessibility provider for dialogs -->
  <a11y-dialog-renderless
    #default="{ backdropRef, dialogRef, titleRef, closeRef, focusRef }"
    @close="$emit('close')"
  >
    <div class="dialog-root">
       <div v-bind="backRef" />
       <div v-bind="dialogRef">
         <!-- you get the point -->
       </div>
     </div>
  </a11y-dialog-renderless>
</template>

and in context

<!-- someView.vue -->
<template>
   <div>
        Some view
       <v-dialog :open="isOpen" v-test="'support-dialog'">
           Need help?!
       </v-dialog>
  </div>

// someView.spec.js
it('renders the support dialog', () => {
   const wrapper = mount(SomeView, { data: () => ({ isOpen: true }) })
   // no longer works
   expect(wrapper.find('[data-test-id="support-dialog"]').exists().toBe(true)
})

Idea

The idea is to give a more or less similar treatment to $attrs and allow to forward directives declared on the component to a desired element node:

1. using the v-bind="$directives" property which would be a map of all passed directives. $directives in this scenario would be prefixed with some internal identifiable string, the same way that listeners are prefixed with "on" onX. Since the v-bind= idea, would require tweaking the parsing of v-bind contents, an alternative idea be a new directive: v-bind-directives or v-directives.

   <!-- VDialog.vue -->
   <template>
     <!-- renderless accessibility provider for dialogs -->
     <a11y-dialog-renderless
       #default="{ backdropRef, dialogRef, titleRef, closeRef, focusRef }"
       @close="$emit('close')"
     >
   -    <div class="dialog-root">
   +    <div class="dialog-root" v-bind="$directives">
          <div v-bind="backRef" />
          <div v-bind="dialogRef">
            <!-- you get the point -->
          </div>
        </div>
     </a11y-dialog>
   </template>
   
   <script>
   export default {
   +  // if fallthrough behaviour is still a thing by that time
   +   inheritDirectives: false
   }
   </script>

2. Similar to $attrs that get their companion useAttrs() function, in a pure composition-api scenario we could also have:
   • useDirectives() composable to return the provided directives map for binding.
   • directives could be destructured from setup() hook context, in a similar fashion

      setup(props, {  directives }) {}

Is it too absurd? Is it just me? Note: I know that there are plenty of ways to work around this particular problem (manually adding a data-test-id and using $attrs and then tweak the compiler config to remove them but that's not the point. There are plenty of other examples that are not as easy to solve as this one, like the O.G custom directive demo v-focus for a component that does not render the <input> as root.

Anyways, just an idea! Cheers 👋

[fanckush]

I like the idea!
maybe changing the title to something like Introduce inheritDirectives: false could help it get some traction

[renatodeleao]

Done, can't hurt and welcome aboard!

[renatodeleao]

1 year after. If anyone else has suggestion on how to make the description better to create more "buzz" let me know.

Note that even customising the directive to target a specific element via binding.value, if the component renders multi-root nodes or a provider/renderless component, vue simply ignores it (and i know it's in the docs). This seems over-zealous from Vue, since a custom directive could bypass this limitation by using binding value and instance to find the target element

More demos:

1. I recreated the original v-focus custom directive form the docs, to allow targeting a specific element in a component. As soon as I turn it into a multi-node component, the directive stops working even if there's not an apparent strong reason for it (IMO of course).
2. Another demo for with a vHighlight directive that fails if use an IdProvider wrapping component inside AppInput (commented out for demo purposes)

Common valid criticisms

1. Move provider components outside and pass bindings as prop
2. just bind the directive internally to desired element or pass a prop as binding value for it. Limitations:
   1. I cannot dynamically binding a directive based on a prop
      1. I would have to internally add "active" option to the binding.value do decide if the directive should effectively run or not on updated callback
   2. I cannot dynamically import a directive and bind it, there's no defineAsyncDirective
      1. My component now carries the directive "weight" even if i just use it a couple of instances.

Final thoughts

I know that there are alternatives for every pattern listed, but a framework provides convenience, that's why we use them primarily. If this is not viable, I think we can safely close this thread.