Recently, VUE author You Yuxi submitted a proposal for Ref syntax sugar on the RFC , which caused controversy in the community.
Briefly, this proposal introduces a new script tag writing method in the Single File Component (SFC) <script setup>, which is written in such a way that it will automatically expose all top-level variable declarations to the template. At the same time <script setup>it introduced a syntactic sugar eliminate the value of the ref attribute of the syntactic sugar automatically syntactic sugar to normal code during compilation.
For example, this HTML code:
<script setup>
// Declare a variable that will be compiled to ref
ref: count = 1
function inc() {
// The variable can be used like a normal value, without .value
count++
}
// Use the $ prefix to correspond to the original ref object
console.log($count.value)
</script>
<template>
<button @click="inc">{{ count }}</button>
</ template
Will be compiled like this:
<script setup>
import { ref } from 'vue'
export default {
setup() {
const count = ref(1)
function inc() {
count.value++
}
console.log(count.value)
return {
count,
inc
}
}
}
</script>
<template>
<button @click="inc">{{ count }}</button>
</templ
Note that label: x = 1 is still valid JS syntax (that is, a labeled assignment statement is equivalent to directly assigning a value to x, and an error will be reported if x is not defined in strict mode), which is equivalent to special processing of the semantics of ref label names.
Why do you want to do this?
Mrs Yu Xi said that on the one hand by the top-level variable automatic exposure can reduce code redundancy; on the other hand, through ref:grammar can make more efficient ref.
Since the birth of the Composition API, everyone has been discussing whether it is better to use ref or reactive objects. Using ref will cause the code to be everywhere .value, and if developers do not use TypeScript, they will often miss writing .value, so many developers do not know how to deal with ref.
In fact, ref exists because of some problems in the JS language: if you don't encapsulate a value in an object, you can't turn this value into a responsive data through the built-in method of JS. This means that if the semantics of JS is not changed, it is impossible to use ref like ordinary variables. In addition, You Yuxi also admitted that he was inspired by the Svelte framework. Svelte has modified the semantics of JS earlier, export let $and Svelte has given it more powerful and convenient functions.
"In the past, we wanted to keep the original semantics of JS as unchanged as possible, because magical changes to JS will bring some problems, but there is always a need to have the "first to eat crabs" to transform JS to provide developers with better development Experience. "You Yuxi said.
Cause controversy
In response to this proposal, many community users expressed their opposition to this proposal. The reason for most people's opposition is that this proposal is too serious for JavaScript magic changes. They question why tag syntax is used instead of directly inventing new syntax, which increases the mental burden of users. and many more.
In response to these queries, You Yuxi himself responded one by one:
About Magic Change JavaScript
ref: count = 1 uses tag syntax, which is legal JavaScript at the syntax level, and can be executed normally in non-strict mode, even the semantics declares a global variable named count. At the same time, this is also a legal TypeScript grammar and will not be confused with type declarations (type declarations must necessarily require let and const)
Of course, this is really just the legal aspects of grammar, in fact, tantamount to
ref:the label given a different semantics. Tag syntax itself is a rarely used feature, the actual use for marking are also declared cycle (used / front while for), as examplesref: count = 1of such usage, which is useless original semantics, which is why We think that sacrificing this primitive semantics to obtain reactive variable declarations is a worthwhile exchange.
Why use tag syntax instead of directly inventing new syntax
The use of tag syntax is indeed inspired by Svelte. The fundamental reason is that maintaining complete compatibility with JS at the syntax level can ensure the ecological docking of existing JS tools as much as possible. The tag syntax can be directly supported by Babel, TS parser/transformer (such as esbuild/swc), Prettier, ESLint and any IDE JavaScript syntax highlighting, only when semantics are involved, such as type inference and ESLint variable related rules Only need targeted compatibility. If a new non-standard syntax is used, it means that all the above tools need to be modified at the parser level, which is basically not feasible.
I feel the mental burden has become heavier
Although the bottom layer is syntactic sugar compiled to ref(), in fact, newcomers don’t need to know the existence of ref() before they can use it, because in the scenario where the underlying ref object does not need to be obtained, the variable mind declared by ref: The model is exactly the same as the mental model of the variables declared with let. The user only needs to treat ref: as a responsive let. This model is enough to achieve most of the entry-level functions. Only when you start to learn logic extraction and reuse after advanced, you need to know the concept of ref().
For users who have already studied the Composition API, they will feel "one more concept". At the same time, since the RFC discusses the compilation rules in detail, it will produce an illusion of "mental burden increased". In fact, when I used CoffeeScript, Babel, or TS a long time ago, I also felt this way, because I like to see what it looks like before using it. The result is that after reading this, I used the upper-level grammar and couldn't help but convert it into the lower-level grammar. But this is essentially a kind of inertia of our brains after getting used to the underlying way of thinking. This inertia quickly disappeared after using the new grammar for a period of time, and our brains are still very adaptable. If you don’t care about the result of the compilation at the beginning, there will be no such problem (when you use nullish coalescing or decorator, do you think about the result of babel/TS compilation?)
For users starting from scratch, as mentioned above ref: is just a let that can trigger a response, and the learning cost is very low.
You Yuxi's original answer: https://www.zhihu.com/question/429036806/answer/1564223482
Finally, You Yuxi said that before the publication of this RFC proposal, he knew that it would cause a lot of controversy, and he also understood that people's first reaction to the new technology was "unacceptable." However, he also said that the proposal may not necessarily be implemented. I hope that you will be rational when discussing it. At the same time, I suggest that you read the full text of the RFC and the discussion on GitHub before raising any questions.
Full RFC: https://github.com/vuejs/rfcs/blob/script-setup/active-rfcs/0000-script-setup.md