前言大家应该都知道，如果使用Vue3的CompositionAPI定义一个reactive变量，通常有两种形式，一种是使用ref，一种是reactive：一般来说，ref是用来定义一个基础数据类型，而引用类型是Reactive会被使用，那么问题就来了。ref虽然定义了一个基本数据类型，但它实际上是一个引用类型。取值赋值时，必须带.value属性：这有点不直观，一不小心就很可能这样写：这个如果有TS和ESLint加持就好了，没有的话就不好找错了，不会产生有用的错误信息，而且每次都带这个.value真的很难看，写起来也很麻烦！reactive的缺点是不能解构，解构会失去响应性：也许有人会说，不是有toRefs吗？有了toRefs，又会回到.value问题：其实我个人觉得还好，因为写习惯了，一直在用TS带提示和自动补全，所以我觉得没什么问题，不过知乎类似to《为什么 vue3 删不掉 ref() 这样冗余的函数，但 svelte 可以？》伤了老大的心，老大自己的强迫症也犯了。毕竟，他当时创建Vue最成功的元素之一就是方便。但是现在这种多余的写法已经和方便没关系了，所以友达无论如何都要解决这个问题，让人家总不能说Vue写起来不如Svelte方便吧？于是大佬创造了三种不同的语法糖，分别是：[《[译]尤雨溪: Ref语法糖提案》](https://juejin.cn/post/689460...)《Vue第二波ref语法提案来袭 这次会进入到标准吗？》本文（第二波语法糖修改版）我们先简单看一下这三种语法糖的写法：第一波语法糖第一波主要是模仿Svelte的写法。我们来看一个Svelte中文官网给出的例子：这个$:是一个叫label的语法，不是Svelte创造的语法，而是一个长期废弃的语法疯狂探索的合法语法在边缘，但这种语法最初并不是这样使用的，它被用在嵌套循环中：letnum=0outermost:for(leti=0;i<10;i++){for(letj=0;j<10;j++){if(i==5&&j==5){continueoutermost}else{console.log(i,j,88)}num++}}console.log(num)//95它不会看不懂也没关系，也没有必要看懂这个语法，因为不够直观，用处不大，所以几乎没人用！当我在编辑器中写这段代码时，ESLint报错：翻译：LabelsyntaxisderivedfromtheGOTOstatement，使用它会使代码难以理解和维护。——ESLint但既然没人用，而且还是JS的合法语法，用它来告诉编译器这里声明了一个ref变量不是很完美吗？所以裕达也创造了一个类似于Svelte的语法：这是因为标签语法根本不是这样使用的。它最初与break和continue一起使用。虽然用在其他地方不算语法错误，但是很明显你修改了JS原有的语义！游达虽然表示不满：为什么斯维尔特用这个东西你不说，我用这个东西你就开始抱怨了？！我个人的感觉是，Svelte说它从一开始就是一个编译器，没有沉重的历史包袱，而Vue正好相反。而Svelte本身也不是主流框架，属于爱折腾的人。但是Vue不一样。有多少人靠Vue谋生？不是每个人都喜欢这么折腾的。于是无奈之下，游达只好放弃了这个求婚，但这件事却一直萦绕在游达的心头，犹如一根刺，他吸收了第一波语法糖教学，重新开始。.起草了新提案：第二波语法糖可以看到我们没有引入变量$ref，这个变量从何而来？它是一个全局变量，只要在$fromRefs是什么？以前没有这样的东西！我只听说过toRefs:这个$fromRefs是为了配合toRefs而创建的。比如我们在别处写了一个useXxx：import{reactive}from'vue'conststate=reactive({x:0,y:0})exportdefault=(x=0,y=0)=>{state.x=xstate.y=yreturntoRefs(state)}所以当我们使用它时：这不就是不想再看到的.value属性吗？？于是$fromRefs的诞生就是为了解决这个问题：最后一个API是$raw，raw不是本义吗？那么从名字就可以猜到，就是我们用$ref创建的其实是一个响应式对象，不是基本数据类型，但是语法糖会让我们在使用过程中使用基本数据类型是可以改变的，但有时我们想看看对象长什么样，这时就需要使用$raw：改进版这个语法糖没多久又改进了。改进版主要是将全局变量改为只有$和$$变量。如果不使用语法糖，我们可以这样写：之后变成这样使用语法糖：如果我们想恢复加载变量，我们需要使用$$:或者可以这样写：第三波语法糖第三波语法糖主要是在第二波语法的基础上改进的，除了很多人觉得$(ref())..这样写太多了。.另一方面实现了props的语法糖。新的语法主要是给每个可以创建.value变量的方法等价一个$前缀，比如：refcomputedshallowRefcustomReftoRef，同时保留改进版的$变量和$$变量用于解构props：要知道以前我们是不能解构props的，现在也可以使用ES6的解构默认值写法来给props设置默认值props:三波语法糖提案地址第一波：https://github.com/vuejs/rfcs/pull/228第二波：https://github.com/vuejs/rfcs/discussions/369第三波：https://github.com/vuejs/rfcs/discussions/413这个框架work明明是中国人用的最多的，但是一群老外在讨论Vue的下一步计划，真是可笑。肯定有人会说：中国人都在忙996，哪有时间讨论那些事……就看你怎么想了：这些乱七八糟的语法糖你不管，语法出来我就学什么,我是一只沉默的羔羊或者说：你只是在这篇文章下面留言说你喜欢这些新语法或者讨厌这些新语法，你也懒得在GitHub上说英语。链接已经发给大家了，就看大家是想凑热闹，还是点开链接，勇敢的发表自己的心声。当然，如果我们去GitHub，还是得会英文。友达虽然能听懂中文，但评论区不全是中文，Vue还是有相当多的外国粉丝。并非所有人都是美国人。那些不是英国人和美国人的开发者，如果他们只想玩得开心，说他们的母语，我想我们是没法交流的。同时，这也将进一步拉近中国人与人之间的距离。海外形象：别人用英文，你们中国人用自己的语言，不守规矩。那么可能会有人的英语水平真的很差。我们可以这样做：找到百度翻译，输入中文翻译成英文，然后把英文复制过来。这样的翻译虽然不一定完全准确，但至少可以勉强听懂。同时，还有一个技巧就是把翻译成英文的句子再翻译回中文，看哪里的语义变化比较大，然后针对那个地方改写。如果你喜欢这个语法，那就去点个赞吧，表扬一下，所以一定要尽快收录到Vue的标准语法中。如果不喜欢，那就赶紧多喷几句吧，所以这个语法很有可能像第一波语法糖提案一样被抛弃。如果你觉得无所谓，那算什么爱，上GitHub多麻烦，直接在本文下发表评论多方便。那么欢迎大家在评论区留言。
