Re-ask: How to get v-model expression?


#1

I have the same question as was asked by someone else here:

I’d like to access the v-model expression so that I can do this:

<my-input v-model='fubar'/>

which follows DRY principle rather than:

<my-input v-model='fubar' title='fubar'/>

which violates DRY.

To do this “my-input” component needs to access the v-model directive expression. Alternately, if I could somehow reference the original DOM element before it is vue-ified, I could extract the v-model expression myself.

Is there some way to do this?

Thanks,

-Dan


How to get v-model expression?
#2

The answer is short: This is not possible.


#3

Thanks, at least that’s conclusive!

Some follow-up questions:

  1. Should I post a feature request?

  2. There’s two ways I can see to work around this:

a) Make my own directive that preserves the expression. If I do this, how can I call the “v-model” directive code from my own “my-v-model” directive? For example, if my custom directive creates a new element with a v-model directive, will this new/modified element be interpreted properly?

b) Make so the “my-input” element gets/sets the data itself. If I do this route, how can I access the data-context that “my-input” is embedded in?

FYI, I already built my app using the “b” technique, but I hit an issue whereby the wrong data is set/gotten when my custom input elements are used inside components that use slots. I suspect I’m just going about accessing the data in the wrong manner.


#4

This has, in my opinion, about 0% probability of being accepted because the technical debt it introduces for saving a few keystrokes is hardly worth it.

So I would advise against doing it.

The first way is technically pretty much impossible.

The second way would be doable for simple scenarios, but would break e.g. when used inside v-for, becaue you lose the loop’s scope. Working around this will introduce bigger inconveniences than those you want to prevent with this.

On the slot issue I can’t say much, since I don’t know how you access the parent data. If you use $parent then yes, you will access the wrong component, and its also hard to reliably work around that since slots can be deeply nested.

Essentially you are getting yourself into an uphill battle you will have a hard time winning, all in the name of saving a few key strokes.

I wouldn’t even say that it’s DRYer in the strict sense, since that principle isn’t about avoiding keystrokes but avoiding repetition of the same logic so that you don’t have to change stuff in x places in your app when refactoring.


#5

Hi Linus,

Thanks for the detailed answer. My applications has hundreds of fields, so the difference in readability of the forms comprising my app is quite significant between having hundreds of repeated field-names vs. not having the repeats.

Vue has let me basically have a domain-specific language for describing my forms which is a big win.

Yes, my input components were searching up the “$parent” component hierarchy for a component that had the field name specified in its data. The problem is that for some reason I can’t understand, the component with slots seems to have a copy of the data I am trying to get/set, and so the input components don’t work right in that case. Any ideas how I can get the correct “data”? I’m fine with having the components not work right in a for-loop – for that case I can revert to using v-model and an explicit duplicated title.

Thanks,

-Dan


#6

BTW, Wikipedia describes DRY as “a principle of software development aimed at reducing repetition of all kinds,” so I’d say this qualifies!


#7

I can’t really picture the behaviour you are describing. can you give a small example?


#8

Hi Linus,

I don’t remember the original problem I was having regarding slots. Probably a mistake on my part.

The answer znck gave in another thread – “this.$vnode.data.model.expression” works well to get the v-model expression.

Given that this functionality is already in the code-base, why would bringing it into the public API incur a significant amount of technical debt? It’s very handy for frameworks.

Thank!