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

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.

Size Report

Bundles

Usages

Open in Stackblitz

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

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

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

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

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

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

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

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

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

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

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

commit:e4fd227

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><Compv-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><Compv-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. seePlayground with this PR

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

@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.

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

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 intransformElement.ts, which will be fine.

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?).

/ecosystem-ci run

📝 Ran ecosystem CI:Open

Thanks@Fuzzyma
Nick work and LGTM~

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?

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

@Fuzzyma

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

We can use the following version to install thePR 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.

Hi, Thanks for this PR 👍

Can you guys please check this StackBlitz playground to see if it's okay to pass downpre-definedvModelTextmodifiers like

• trim
• number
• lazy

To the custom Input component?

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

Updated the StackBlitz, added input withdefineModel, it worked nicely

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

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

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

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

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 ofmodifiers 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 avoiddefineModel only partially fixes the problem:

• Playground

The modifiers now make it to the child component, but passing them to the<input> won't help becausetrim is applied in thecreated hook ofvModelText.

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 usev-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')">

Heremods might be a key modifier, or one of the general modifiers likestop orprevent. To get this working, the logic that's currently handled in the compiler would need to be implemented at runtime.

@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.