Adding a .v shortcut for .value

[tintin10q]

What problem does this feature solve?

To access the value of a ref() you use .value. While .value is very explicit it is maybe also too long? I suggest adding a .v shortcut for .value.

The use case for .v is the same as .value but just a neat shortcut. I think this will improve the end user experience because you have to do less typing. Shortcuts can make using a framework more enjoyable just like the : shortcut for v-bind and @ for v-on.

I also think it is nice because the framework is called Vue and then access the .v attribute the whole time. But it should also make bundle sizes smaller because .v is 5 times as less text than .value and this might make a difference if you have a large project.

I think .v still makes it as clear what you are doing as .value but it is just much faster and nicer to type.

What does the proposed API look like?

Here is are two examples:

<script setup>
import {ref} from 'vue';

const counter = ref(3);

function increment() {
  counter.v++;  
}

</script>

You could also mix them:

<script setup>
import {ref} from 'vue';

const counter = ref(1);
const counter2 = ref(2);

function increment() {
  counter.v++ 
  counter2.value++
}

</script>

[yyx990803]

I've actually thought about this, but .v would look too cryptic IMO.

Something like .val could be short but still legible.

[jacekkarczmarczyk]

It's not more cryptic than $$ stuff from reactivity transform
I personally don't mind .value, but I was thinking about $ for the replacement of value to make it short and somehow similar to reactivity transform. See the example, both are for me similarly cryptic:

// reactivity transform
let count = $ref(0)
trackChange($$(count))

// .value replacement
const count = ref(0);
doSomething(count.$)

Another reason is that it's easily searchable (searching for .v may find much more results than you'd expect while searching for .$ should be more accurate)

[tintin10q]

I've actually thought about this, but .v would look too cryptic IMO.

Something like .val could be short but still legible.

That is why it should be a shortcut. .value is not cryptic and then .v is the shortcut. Just like v-on is not cryptic and than @ is the shortcut.

[zhenzhenChange]

duck不必

[yyx990803]

FYI I moved this to RFCs discussions.

[jods4]

My vote is a no.

This is cryptic and introduces 2 different names for the same thing.
I would be in favor if there was a large benefit but I fail to see it.

I have written plenty of code with .value and I don't see a big issue.
It's really not that long that "typing" is a problem.
I read code more often that I write it, and .value is undeniably more clear than .v, even more so for newcomers.
Soon reading/writing arguments will be even less important as people will be able to use $ref and not use .value anymore in most cases.

it should also make bundle sizes smaller because .v is 5 times as less text than .value and this might make a difference if you have a large project.

I would love to see some real numbers before this is used as an argument, because I doubt it'd make a significant difference, especially not after gzip.

.val is an alternative I would be ok with as it's long enough to convey some meaning, a bit like ref. It's a bit late for that, though: at this point I don't think trimming 2 chars from a name is worth introducing synonyms in public apis.

[jacekkarczmarczyk]

@jods4

This is cryptic and introduces 2 different names for the same thing.

The same argument can be applied to @, # or $$ (the latter one at least in terms of being cryptic, because just looking at the name I have no idea what it does). There's also function h with very meaningful name which seems to be broadly accepted.

To be clear - I'm not advocating for .v or .$ (although if I was forced to choose between shortcut for .value or reactivity transform I'd probably choose the shortcut), but i don't think this argumentation is valid.

[jods4]

Just because we have some doesn't mean we need more.
That line of reasoning validates repeating any error you made in the past.
BTW I'm not a big fan of $$ naming, as you might guess.

On the line right after your quote I wrote:

I would be in favor if there was a large benefit but I fail to see it.

If there is a strong argumentation that we need .v, or .val, or something else, why not.
Personally I'm not convinced right now.

I read the issue again and the arguments are:

• it's too long to type, which I don't quite agree with. And this argument is weakened by the introduction of $ref sugar, which aims to solve the same thing by removing the property completely. How many different solutions to a single problem do we need?
• bundles will be smaller, which can be a valid point but I'm skeptical and would like to see some hard data from big projects to validate the argument.

[tintin10q]

Now that I have read your responses I think that .value is indeed nice and explicit as it should be and having mutliple ways to do something is usually not really a good thing.