feat(compiler-core): allow directive modifiers to be dynamic (fix #8281)

[Fuzzyma]

fix #8281

This PR adds dynamic modifiers for directives

<div v-foo.[myModifiers]="5" />

const myModifiers = {
  mod1: true,
  mod2: false
}

It also adds error states for empty modifiers (v-foo.="5") and handles empty dynamic modifiers or invalid values e.g. v-foo.[]="5", v-foo.[123]="5".

I skipped modifiers with invalid values. I am not sure if that is a problem. Otherwise codegen would be corrupted (it was before for empty values already. That's also fixed with that).

I also had to change modifiers to be an Expression instead of SimpleExpression so that I can use parseExpression with it. That means I had to cast to SimpleExpression at a few places

[Fuzzyma]

I developed on top of the main branch but the guidelines say to submit against minor. Now I have this extra commits in my history. Not sure how to handle this

[edison1105]

I developed on top of the main branch but the guidelines say to submit against minor. Now I have this extra commits in my history. Not sure how to handle this

fixed by merging main into the minor branch.

[github-actions[bot]]

Size Report

Bundles

File	Size	Gzip	Brotli
runtime-dom.global.prod.js	102 kB	38.4 kB	34.6 kB
vue.global.prod.js	160 kB (+838 B)	58.5 kB (+230 B)	52.1 kB (+288 B)

Usages

Name	Size	Gzip	Brotli
createApp (CAPI only)	47.1 kB	18.5 kB	16.9 kB
createApp	55.7 kB	21.6 kB	19.7 kB
createSSRApp	59.9 kB	23.3 kB	21.2 kB
defineCustomElement	60.5 kB	23.2 kB	21.1 kB
overall	69.8 kB	26.7 kB	24.3 kB

[pkg-pr-new[bot]]

Open in Stackblitz

@vue/compiler-core

npm i https://pkg.pr.new/@vue/compiler-core@12913

@vue/compiler-dom

npm i https://pkg.pr.new/@vue/compiler-dom@12913

@vue/compiler-ssr

npm i https://pkg.pr.new/@vue/compiler-ssr@12913

@vue/compiler-sfc

npm i https://pkg.pr.new/@vue/compiler-sfc@12913

@vue/reactivity

npm i https://pkg.pr.new/@vue/reactivity@12913

@vue/runtime-core

npm i https://pkg.pr.new/@vue/runtime-core@12913

@vue/runtime-dom

npm i https://pkg.pr.new/@vue/runtime-dom@12913

@vue/server-renderer

npm i https://pkg.pr.new/@vue/server-renderer@12913

@vue/shared

npm i https://pkg.pr.new/@vue/shared@12913

vue

npm i https://pkg.pr.new/vue@12913

@vue/compat

npm i https://pkg.pr.new/@vue/compat@12913

commit: e4fd227

[edison1105]

Thank you very much for your contribution. This PR is really great. I did a quick test and found the following issues.

• v-model dynamic modifiers on component

the following template

<template>
  <Comp v-model.[mod]="msg"/>
</template>

should be compiled to:

_createVNode($setup["Comp"], {
      modelValue: $setup.msg,
      "onUpdate:modelValue": _cache[1] || (_cache[1] = $event => (($setup.msg) = $event)),
-      modelModifiers: { "$setup.mod": true }
+      modelModifiers: Object.assign({}, $setup.mod)
    }, null, 8 /* PROPS */, ["modelValue"])

---

• v-model static modifiers + dynamic modifiers on component

the following template

<template>
 <Comp v-model.number.[mod]="msg"/>
</template>

should be compiled to:

_createVNode($setup["Comp"], {
      modelValue: $setup.msg,
      "onUpdate:modelValue": _cache[1] || (_cache[1] = $event => (($setup.msg) = $event)),
-      modelModifiers: { number: true, "$setup.mod": true }
+      modelModifiers: Object.assign({number:true}, $setup.mod)
    }, null, 8 /* PROPS */, ["modelValue"])

---

• v-model dynamic modifiers with plain object on component

the following template should not cause a compilation error. see Playground with this PR

<Comp v-model.[{ number: true }]="msg"/>

[Fuzzyma]

@edison1105 thanks for the super fast feedback. Am I correct to assume, that your failing cases are specific to the v-model directive or does it happen with any other? (it shouldnt)

For the last error: The "expression missing" error shadows the "whitespace forbidden" error. The same happens if you use whitespaces in the dynamic argument:

Playground link

When I tried try this with the template-explorer it correctly showed the error for other directives that are not v-on or v-model: End bracket for dynamic directive modifier was not found. Note that dynamic directive modifier cannot contain spaces.:

Playground link

Since this is already bahavior thats valid for args, maybe its ok for modifiers as well? Wdyt?

I am not against allowing spaces in dynamic args and modifiers but I am pretty sure it would break formatters and syntax highlighters. I guess thats also the reason why its not supported.

I would have written a test for that as well but I couldnt find where to put it.

[Fuzzyma]

I have a bit of duplicated code now. Let me know if I should refactor that and if so, where I put helper functions for such things

[edison1105]

I have a bit of duplicated code now. Let me know if I should refactor that and if so, where I put helper functions for such things

We can just put them in transformElement.ts, which will be fine.

[Fuzzyma]

Had to complicate the if statements a bit to deduplicate the logic but I think its all good now. The shared function also has the benefit of reusing the SimpleExpression case for all modifiers. So if those mods are ever checked for its patch flags, they will be constant (currently they are always patched i think?).

[edison1105]

/ecosystem-ci run

[vue-bot]

📝 Ran ecosystem CI: Open

suite	result	latest scheduled
language-tools	:x: failure	:white_check_mark: success
nuxt	:white_check_mark: success	:white_check_mark: success
pinia	:white_check_mark: success	:white_check_mark: success
primevue	:white_check_mark: success	:white_check_mark: success
quasar	:white_check_mark: success	:white_check_mark: success
radix-vue	:white_check_mark: success	:white_check_mark: success
router	:white_check_mark: success	:white_check_mark: success
test-utils	:white_check_mark: success	:white_check_mark: success
vant	:white_check_mark: success	:white_check_mark: success
vite-plugin-vue	:white_check_mark: success	:white_check_mark: success
vitepress	:white_check_mark: success	:white_check_mark: success
vue-i18n	:white_check_mark: success	:white_check_mark: success
vue-macros	:x: failure	:x: failure
vuetify	:x: failure	:white_check_mark: success
vueuse	:white_check_mark: success	:white_check_mark: success
vue-simple-compiler	:white_check_mark: success	:white_check_mark: success

[edison1105]

Thanks @Fuzzyma Nick work and LGTM~

[Fuzzyma]

Seems like I broke some runtime directive in vuetify :D. Have to check that... language-tools is mostly ast problems i think.

Guess I have some more work to do. What is the process for this? Do I open a PR in language tools to support the new ast shape and get that merged before this PR gets merged?

[Fuzzyma]

@edison1105 can i somehow checkout this PR ins vue-sfc to test it easily?

[edison1105]

@Fuzzyma

can i somehow checkout this PR ins vue-sfc to test it easily?

We can use the following version to install the PR preview package

npm i https://pkg.pr.new/vue@12913 
// or 
npm i https://pkg.pr.new/vue@e4fd227 // latest commit 

Do I open a PR in language tools to support the new ast shape and get that merged before this PR gets merged?

We should wait for this PR to be shipped.

[sadeghbarati]

Hi, Thanks for this PR 👍

Can you guys please check this StackBlitz playground to see if it's okay to pass down pre-defined vModelText modifiers like

• trim
• number
• lazy

To the custom Input component?

https://stackblitz.com/edit/vitejs-vite-cga23nxl

---

Updated the StackBlitz, added input with defineModel, it worked nicely

This PR is so great, please consider merging it sooner 💯

[Fuzzyma]

@sadeghbarati what exactly should we test in that example? It seems to work just fine, right? I need more context

[sadeghbarati]

I am here to ask whether this is a good practice or not?

Cause I saw somewhere that was mentioned the modelValue modifiers should be re-defined in the child component even if the modifier already exists in Vue internal like trim/number/lazy

[Fuzzyma]

well it does work so i dont see anything bad with doing that. However, this is not the right place to discuss this!

[skirtles-code]

This feedback might be better placed on an RFC. I'm not aware of an RFC for this feature, so I've added it here instead.

---

If I've understood correctly, this PR only adds compiler support, but it doesn't account for the impact at runtime. Perhaps that was the intention, but I don't see this discussed anywhere. I think one of the main reasons why this feature hasn't been added earlier is because making the modifiers dynamic poses various challenges at runtime.

For example, defineModel doesn't support changing the modifiers:

• Playground

const [model, modifiers] = defineModel()

The value of modifiers is captured when the component is created and won't update if new modifiers are passed from the parent. In the example above, checking the checkbox won't change anything in the child.

But rewriting it to avoid defineModel only partially fixes the problem:

• Playground

The modifiers now make it to the child component, but passing them to the <input> won't help because trim is applied in the created hook of vModelText.

This is one specific example, but the problem is a general one: all directives will now need to account for modifiers changing, as well as any components that use v-model modifiers. While this may have been theoretically possible previously via render functions, I don't think there was any real expectation that modifiers could change beyond their initial values. I think introducing template syntax for dynamic modifiers will change that expectation.

---

There are also some modifiers that are resolved at compile-time, which can't work if they're dynamic. e.g.:

• Playground

<input @keydown.[mods]="console.log('second')">

Here mods might be a key modifier, or one of the general modifiers like stop or prevent. To get this working, the logic that's currently handled in the compiler would need to be implemented at runtime.

[Fuzzyma]

@skirtles-code thank you for the in-depth feedback! You are right. I totally forgot about the RFC procedure and jumped the gun. If you want, I can take a step back and prepare an RFC for this feature to let it go the normal route.

Meanwhile: I do agree with you, that modifiers were always perceived as static and that this PR might "damage" that perception. I think that modifiers should stay static for the issues you mentioned and it should be made very clear in the docs, that this feature is intended only for modifiers to be dynamic and not reactive.

However, just in case, reactive modifiers should become a thing, I could see defineModel work exactly like defineProps in that it returns reactive variables that are tracked by the compiler to stay in a reactive context. All the other problems aside, this could be a fix for this specific problem (again, i dont think its a good idea)

There are also some modifiers that are resolved at compile-time, which can't work if they're dynamic.

Yes, that is a problem indeed (Beside the fact, that this is still not correctly compiled as of right now). The only solution I can think of my head is to treat all dynamic modifiers as both - keys and guards. Since no key is named "prevent" or "stop" and no guard is named "a", this should work because unknown keys and guards are dropped.

Basically let it compile to this:

_withKeys(_withModifiers($event => (console.log('second')), [mods]), [mods]))

What do you think? It is runtime overhead but specifically only for dynamic modifiers.