Home >Web Front-end >Vue.js >Note that Vue's reactive syntactic sugar has been deprecated!
This article brings you the latest situation about Vue. It mainly talks about the responsive syntax sugar in Vue. Friends who are interested can take a look at it together. I hope it will be helpful to everyone.
Since the introduction of the concept of composite APIs, a major unsolved problem has been ref# Which one should I use between ## and
reactive?
reactive has the problem of losing responsiveness due to deconstruction, while
ref needs to be used everywhere
.value feels cumbersome and can easily be missed without the help of the type system. Drop
.value.
<template> <button @click="increment">{{ count }}</button> </template>Use
ref to define the
count variable and
increment method:
let count = ref(0) function increment() { count.value++ }Using responsive syntax sugar, we can write code like this:
let count = $ref(0) function increment() { count++ }
The method is a
compile-time macro command. It is not a real method that will be called at runtime, but is used as a marker for the Vue compiler to indicate the final count The variable needs to be a
reactive variable.
with
.value after compilation. So the code in the above example will also be compiled into the syntax defined using
ref.
has a corresponding macro function prefixed with
$. Including the following APIs:
ref
Convert to reactive variables.
const a = ref(0) let count = $(a) count++ console.log(a.value) // 1
ref
.
let count = $ref(0) console.log(isRef($$(count))) // true
also works with destructured props
since they are also reactive variables. The compiler will efficiently do the conversion through toRef
: <pre class="brush:php;toolbar:false">const { count } = defineProps<{ count: number }>()
passAsRef($$(count))</pre>
Configuration
, and Must be used via the build step.
Required, requires
// vite.config.js export default { plugins: [ vue({ reactivityTransform: true }) ] }
script.refSugar
, because it is not only Only effective for SFC.
build, vue-loader@>=17.0.0
is required. It is currently only effective for SFC. <pre class="brush:php;toolbar:false">// vue.config.js
module.exports = {
chainWebpack: (config) => {
config.module
.rule('vue')
.use('vue-loader')
.tap((options) => {
return {
...options,
reactivityTransform: true
}
})
}
}</pre>
If
vue-loader
is built, vue-loader@>=17.0.0
is required, currently only for SFC. effect. <pre class="brush:php;toolbar:false">// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /\.vue$/,
loader: 'vue-loader',
options: {
reactivityTransform: true
}
}
]
}
}</pre>
TS2304: Cannot find name '$ref'.
, although it does not It affects the use, but it will affect the development experience:
"compilerOptions":{ "types": ["vue/ref-macros"] }
ESLint: '$ ref' is not defined.(no-undef)
:
module.exports = { ...globals: { $ref: "readonly", $computed: "readonly", $shallowRef: "readonly", $customRef: "readonly", $toRef: "readonly", } };
tsconfig.json
and eslintrc
in the second and third steps.
import { $ref } from 'vue/macros' let count = $ref(0)
As many of you already know, we have officially abandoned this RFC by consensus of the team.
reasonThe original goal of Reactivity Transform was to improve the developer experience by providing a cleaner syntax when dealing with reactive state. We're releasing it as an experimental product to gather feedback from real-world usage. Despite these proposed benefits, we discovered the following issues: Losing Due to (1), some users choose to only use Reactivity Transform inside SFC, which creates inconsistencies and context switching costs between different mental models. So the dilemma is that using it only inside SFC will lead to inconsistencies, but using it outside SFC will hurt maintainability. Since there will still be external functions that expect to use raw references, conversion between reactive variables and raw references is inevitable. This ended up adding more learning content and additional mental load, which we noticed was more confusing for beginners than the normal Composition API. The most important thing is the potential risk of fragmentation. Although this is an explicit opt-in, some users have expressed strong opposition to the proposal due to concerns that they will have to work with different code bases where some have opted in to use it and others No. This is a legitimate concern because Reactivity Transform requires a different mental model and distorts JavaScript semantics (variable assignments can trigger reactive effects). All things considered, we feel that using this as a stable feature will cause more problems than benefits and is therefore not a good trade-off. Migration Plan Message ... Recommended study: "vue.js video tutorial"
.value
makes it harder to tell what is being tracked and which line triggered the reactive effect . This problem is less obvious in small SFCs, but in large code bases the mental overhead becomes more obvious, especially if the syntax is also used outside of SFC .
ref.value
part that does the conversion? What about reactive props
Deconstruction, is it here to stay? .value
now avoid ref()
if possible and use reactive()
like before? .value
is the necessary complexity. Just like any other reactive library xxx.set()
.
The above is the detailed content of Note that Vue's reactive syntactic sugar has been deprecated!. For more information, please follow other related articles on the PHP Chinese website!