关于前端:译尤雨溪-Ref语法糖提案

前言

最近 ref 的语法糖引起了极大的争议，很多人也是没看 RFC 就间接开喷，尽管我也不喜爱这种语法，但还是有必要让大家看一看在 GitHub 上的提案，看看国外开发者们广泛都是些什么态度，是否和咱们持有同样的观点，提案是 RFC 228，但 RFC 228 其实是为了不便与另一个提案辨别开而新开的，原提案是 RFC 222，它最终被分解成了 RFC 227 和 RFC 228，所以咱们先从 RFC 222 开始翻译。

译文

尤雨溪

简介

• 在单文件组件 (xxx.vue) 中引入了一个新的 script 类型：<script setup>，这种写法会主动将所有顶级变量申明裸露给 <template> 应用。
• 介绍一个基于编译器的语法糖，这种语法糖能够在 <script setup> 中让你的 ref 不必再写 .value 属性了。
• 留神，本提案意在代替 RFC 182 提出的 <script setup> 写法。

根本用法

1. <script setup> 间接向 <template> 裸露顶级变量

⚠️译者注: 顶级变量就是没申明在块级作用域外面的变量

<script setup>
// 引入的 Foo 组件能够间接在 template 里应用了！import Foo from './Foo.vue'
  
import {ref} from 'vue'

// 就像在一般的 setup() 中一样编写 Composition API 代码，// 无需手动返回所有内容
const count = ref(0)
const inc = () => { count.value++}
</script>

<template>
  <Foo :count="count" @click="inc" />
</template>

???? 下面的这段代码将会编译成上面这样????：

<script setup>
import Foo from './Foo.vue'
import {ref} from 'vue'

export default {setup() {const count = ref(1)
    const inc = () => { count.value++}

    return {
      Foo, // 即便 Foo 组件不是被申明的，也会把它算作顶级变量
      count,
      inc
    }
  }
}
</script>

<template>
  <Foo :count="count" @click="inc" />
</template>

1. ref:语法糖令代码更简洁

<script setup>
// 申明一个变量(这个变量将会被编译成一个 ref)
ref: count = 1

function inc() {
  // 该变量能够像一般变量那样应用
  count++
}

// 想要获取到本来的变量的话须要在变量后面加一个???? 符号
console.log($count.value)
</script>

<template>
  <button @click="inc">{{count}}</button>
</template>

???? 下面的这段代码将会编译成上面这样????：

<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>
</template>

评论之前:

• 请确保曾经读完残缺的 RFC
• 请不要简略地答复 ” 我喜爱 / 我不喜爱 ”- 它不会对探讨做出有意义的奉献。
• 如果不赞成该提案，请在动机和弊病中提出的观点范畴内进行具体论证。请留神，这中语法是 JavaScript 中的标签语法。咱们只是给 ref: 这个标签提供了不同的语义。这就像在 HTML 写 Vue 指令一样。

⚠️译者注：而后接下来是高赞回复：

耶姆贾森(ycmjason ????????)

只是一个意见：

真的不喜爱这个主见。发明的语法太多了。而且这曾经不再是 JavaScript 了。

尤雨溪(回复)

你这种反馈在咱们的意料之中，我晓得这可能会引起争议，因而对于其余任何评论：

• 请确保曾经读完残缺的 RFC
• 请不要简略地答复 ” 我喜爱 / 我不喜爱 ”- 它不会对探讨做出有意义的奉献。
• 如果不赞成该提案，请在动机和弊病中提出的观点范畴内进行具体论证。

私人号码(privatenumber ???????? ????????)

编译器会主动将所有导入的 xxx.vue 文件注册为组件吗？

具体来说，我很好奇编译器怎么辨认什么是 Vue 组件，什么不是。如果我导入一个 xxx.js 模式的组件，那还能够应用吗？

如果咱们用到了高阶组件的话，也可能不心愿这个导入的高阶组件被主动注册成组件。

如果咱们要增加自定义语法，那么 ES2021 的 export default from 语法是否能够施行？

我感觉这种写法可能既简洁又明确：

export {default as Foo} from './Foo.vue';

尤雨溪(回复)

编译器能够通过 setup 上下文来判断。模板编译器会从 script 编译时提取绑定信息判断该组件是否可用。

我认为导入 xxx.vue 并利用高阶组件的模式去包装是十分常见的一种状况。在这种状况下，您能够应用独自的惯例 <script> 标签用以前的形式去注册组件。

必图(btoo ????????)

我宁愿用 svelte 的 $: 而不是 svelte-ref: 这种模式。

其实也能够通过在变量名前增加一个 $ 前缀来放弃拜访原始 ref 的形式。

⚠️译者注：svelte 是国外另一款特地火的框架，这个提案的灵感就来源于这个 svelte 的写法

约翰逊(johnsoncodehk ????????)

⚠️译者注：这个人不是高赞 (????)，而是高踩(????)，咱们看看也别光看高赞，高踩也挺有意思
$: + let / const 这种写法怎么样怎么样？
就像这样：

$: let foo = 1 // 这个变量代表 ref
$: const bar = foo + 1 // 这个变量代表 computed
$: let baz = computed(() => bar + 1)

而后会被编译成这样：

const $foo = ref(1)
let foo = unref($foo)
const $bar = computed(() => foo + 1)
const bar = unref($bar)
const $baz = ref(computed(() => bar + 1))
let baz = unref($baz)

我感觉大家如同都不想脱离 js 的语义，当然咱们能够有一种齐全基于 js 语义的办法，但这是咱们想要的吗：

import {noValueRef, noValueComputed} from 'vue'
let foo = noValueRef(1) // TS 类型: number & {raw: Ref<number>}
const bar = noValueComputed(() => foo + 1) // TS 类型: number & {raw: ComputedRef<number>}
useNum(bar.raw)
function useNum(num: Ref<number>)

而后会被编译成这样：

import {ref, computed} from 'vue'
let foo = ref(1)
const bar = computed(() => foo.value + 1)
useNum(bar)
function useNum(num: Ref<number>)

喜爱的点赞(????)，不喜爱就踩(????)

⚠️译者注：下面那句话是他说的不是我说的，果然亚洲都喜爱玩这一套

罗宾鲍乌(RobbinBaauw ????????)

这个 RFC 的毛病 (<script setup> 自身也是一个毛病，但当初变得更糟) 是编写大量雷同内容的 options。经验丰富的 Vue 开发者 (例如对此 RFC 进行评论的这帮人) 理解所有的 options，理解它们之间的关系等，然而对于 Vue 的大部分开发者而言，状况并非如此。

在 Vue2 中，只有 Options API，最终咱们会失去一个相似类一样的组件。然而如果用了这个 RFC，咱们将会面临以下抉择：

• Options API
• Class API (须要用插件)
• Composition API (vue2 和 vue3 的写法也不一样)
• \<script setup> 搭配 ref: 语法糖
• \<script setup> 不搭配语法糖

这会让用户群变得十分扩散，让刚入门的小白和有抉择艰难症的人感觉太难了。如果只须要记住：” 想要响应式就用 Options API，不便逻辑复用就用 Composition API” 的话那就会简略多了。

然而很显著，不少人喜爱这种 ” 神奇的 ” 语法。如果有人再提出个什么自定义的语法说不定当前还会想再扩大语法，能不能在 Vue 以外的第三方库去实现它？如果这是 Vue 的外围语法，那么在当前的 Vue 版本中都将须要反对它。

我认为这个 $ 十分令人纳闷：如果您不齐全理解 $ 前缀的前因后果，我认为这将会令人十分纳闷！也就是说，须要晓得一个这玩意是个 ref 的理论值，并且还须要晓得本人正在解决的是一个加了语法糖的 ref，在这种状况下须要给它加上 $ 前缀，而在其余状况下，则不须要加前缀。我深信这会给许多用户带来很多问题。

尤雨溪(回复)

你说的太夸大了。

Class API 是一个官网插件，但只是一个插件。不是外围 API 的一部分，仅吸引特地偏爱 Class 的用户。换句话说，它不是 ” 支流 ”。

⚠️译者注：不是支流那不就是 非主流？

vue2 和 vue3 的 Composition API 的目标是雷同的，并且即便不是全副，也至多是大多数代码看起来雷同。渺小的技术差别不会将它们视为 ” 做同一件事的两种形式 ”。

<script setup> 就如 RFC 中所倡议的那样，用不含语法糖编写的 Composition API 代码与失常的 Composition API 应用状况 100% 雷同 ( 除了无需手动返回所有内容)。实际上，如果用户应用的是但文件组件的话，因为前者总是只用写更少的代码，所以我真找不到不必新 <script setup> 的理由。

难道你感觉这么写更好吗：

export default {components: {...},
  setup() { ...}
}

ref:是纯语法糖。它不会扭转 <script setup> 外面 Composition API 的工作形式。如果你曾经了解了 Composition API，那么了解 ref: 语法糖不会超过 10 分钟。

综上所述 - 有两个 ” 范例 ”：
（1）Options API
（2）Composition API
<script setup> 和 ref: 语法糖不是不同的 API 或范例。它们只是 Composition API 的扩大，能够用更少的代码来表白雷同的逻辑。

(援用罗宾方才说的话)：如果有人再提出个什么自定义的语法说不定当前还会想再扩大语法，能不能在 Vue 以外的第三方库去实现它？

所以，你也批准很多人都心愿应用 ref: 语法糖，然而却倡议不要在 Vue 中反对它，而是激励各种第三方库各自实现本人的语法。这不是只会导致更多的碎片化吗？想想 React 生态系统中的 CSS-in-JS。

(援用罗宾方才说的话)：我认为这个 $ 十分令人纳闷：如果您不齐全理解 $ 前缀的前因后果，我认为这将会令人十分纳闷！也就是说，须要晓得一个这玩意是个 ref 的理论值，并且还须要晓得本人正在解决的是一个加了语法糖的 ref，在这种状况下须要给它加上 $ 前缀，而在其余状况下，则不须要加前缀。我深信这会给许多用户带来很多问题。。

$foo 其实就代表 foo 就好比 foo 就代表 foo.value。真的那么令人蛊惑吗？这会导致什么确切的具体问题？遗记 $ 何时增加？请留神，即便没有语法糖，咱们也遗记什么时候该用.value，后者更可能产生。

你是在要求用户放弃 Composition API 的益处，因为您不喜爱语法糖，因为语法糖会使 Composition API 变得不太简短。我真的认为没有情理。

林纳斯·伯格(LinusBorg ????????)

如果 <script setup> 当初间接向 <template> 模板公开顶级变量

那将如何解决两头变量：

const store = inject('my-store')

ref: stateICareAbout = computed(() => store.state.myState)

function addState(newState) {store.add(newState)
}

即便 store 这个变量不须要公开到 <template> 下来，也会裸露给 <template> 模板。但这实际上是一个问题吗？

不利的一面是: 它将使生成的代码变大，因为它会使设置返回的对象变大，并且咱们对模板所裸露的内容失去了一些 ” 清晰度 ”。

从好的方面来说，人们可能会辩论说，明确定义裸露于模板的内容太麻烦啦，感觉 <template> 当初更像是 JSX 了。

尤雨溪(回复)

是的，所有顶级变量都会裸露在外。从技术上讲，如果将其合并，咱们还能够引入另一种模板编译模式，在该模式下，间接从 setup 中 return 一个 render 函数。这使得作用域更加间接，并且防止了 render proxy。

埃勒夫(iNerV ????????)

这太蹩脚了。我不想在 Vue 中看到 svelte。(不想看到不非法的 js 语法)

总结

总体来说，持拥护态度的人占多数，和国内差不多，不过看到这么多不同国籍的人在这里探讨还挺有意思的，然而中国???????? 的声音却非常少，好不容易看到一个还是香港???????? 的，大家也能够去 GitHub 上间接舌战群儒。

当然哈，别用中文，毕竟你要让所有国籍的人都能看懂 ( 至多是勉强看懂，我翻译荷兰那小子的英文，感觉说的也不咋地，咱们英文不比他们差)，设想一下这些人如果都用本人的母语发表观点的话咱们还怎么读懂。强行用中文的话同胞们看着是难受了，然而会导致咱们在国内上的名声进一步下滑。

大家在去 GitHub 探讨的时候还是要尽量维持一下咱们国家在国内上的形象哈！

该文章首发于公众号：《前端学不动》