Introduce inheritDirectives: false
#480
Replies: 2 comments 1 reply
-
I like the idea! |
Beta Was this translation helpful? Give feedback.
-
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 More demos:
Common valid criticisms
Final thoughtsI 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. |
Beta Was this translation helpful? Give feedback.
-
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 av-test="'some-id'"
directive to target my elements and components. The only thing this directive does is conditionally adddata-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. Withvue@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 haverenderless/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 invue@2
and now it doesn't.Example
and in context
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: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 thev-bind=
idea, would require tweaking the parsing ofv-bind
contents, an alternative idea be a new directive:v-bind-directives
orv-directives
.$attrs
that get their companionuseAttrs()
function, in a purecomposition-api
scenario we could also have:useDirectives()
composable to return the provided directives map for binding.directives
could be destructured fromsetup()
hook context, in a similar fashionIs 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 demov-focus
for a component that does not render the<input>
as root.Anyways, just an idea! Cheers 👋
Beta Was this translation helpful? Give feedback.
All reactions