[Перевод] Yuxi You: Ref Syntax Sugar Proposal

Vue.js

предисловие

В последнее время синтаксический сахар ref вызывает много споров, и многие люди просто распыляют его, не читая RFC.Хоть мне и не нравится такой синтаксис, но все же всем необходимо взглянуть на предложение на GitHub и Посмотрите на зарубежные страны.Каково отношение разработчиков в целом?Они придерживаются тех же взглядов, что и мы?ПредложениеRFC 228,ноRFC 228На самом деле оно было открыто заново для удобства отличить его от другого предложения.Первоначальное предложение былоRFC 222, который окончательно разлагается наRFC 227а такжеRFC 228, поэтому начнем сRFC 222Начать перевод.

перевод

Ю Юси

Введение

  • в однофайловом компоненте (xxx.vue) вводит новый тип скрипта:
  • Представляет синтаксический сахар на основе компилятора, который избавляет вашу ссылку от необходимости писать свойство .value в .
  • Обратите внимание, что это предложение предназначено для замены нотации

Основное использование

⚠️Примечание переводчика: переменная верхнего уровня — это переменная, которая не объявлена ​​в области видимости блока.

<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: tag разную семантику. Это похоже на написание директив Vue в HTML.

⚠️Примечание переводчика: затем последовал ответ Гао Цзаня:

ycmjason 🇷🇺

Просто мнение:

Очень не нравится идея. Слишком много грамматик для создания. И это уже не JavaScript.

Ю Юси (ответ)

Ваша реакция ожидаема, и я знаю, что она может быть спорной, поэтому для любых других комментариев:

  • Пожалуйста, убедитесь, что вы прочитали полностьюRFC
  • Пожалуйста, не отвечайте просто "мне это нравится/мне это не нравится" - это не внесет значимого вклада в дискуссию.
  • Если вы не согласны с этим предложением, пожалуйста,мотивацияа такженедостаткиПриводятся конкретные аргументы в рамках представленных точек зрения.

личный номер (личный номер 🇺🇸 🇯🇵)

Будет ли компилятор автоматически регистрировать все импортированные файлы xxx.vue как компоненты?

В частности, мне любопытно, как компилятор распознает, что является компонентом Vue, а что нет. Если я импортирую компонент в виде xxx.js, он все равно будет работать?

Если мы используем компоненты более высокого порядка, мы можем не захотеть, чтобы импортированные компоненты более высокого порядка автоматически регистрировались как компоненты.

Если мы хотим добавить собственный синтаксис, то ES2021export default fromЯвляется ли грамматика реализуемой?

Я думаю, что этот способ написания может быть как кратким, так и явным:

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

Ю Юси (ответ)

Компилятор может определить это по контексту установки. Компилятор шаблона извлечет информацию о привязке из времени компиляции скрипта, чтобы определить, доступен ли компонент.

Я думаю, что очень редко можно импортировать xxx.vue и применить оболочку в виде компонентов более высокого порядка. В этом случае вы можете использовать отдельный обычный тег

Обязательная фотография (btoo 🇺🇸)

Я бы предпочел использовать svelte$:вместоsvelte-ref:эта форма.

Также можно сохранить доступ к исходной ссылке, поставив перед именем переменной префикс $.

⚠️Примечание переводчика: svelte — еще один очень популярный за рубежом фреймворк, вдохновение для этого предложения исходит от написания этого svelte

джонсонкодек 🇭🇰

⚠️Примечание переводчика: Этот человек не высокой похвалы (👍), а высокой похвалы (👎), давайте посмотрим и не просто смотрим на высокую оценку, высокая оценка тоже очень интересна

$:А как насчет +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>)

Нравится (👍), если не нравится, нажмите (👎)

⚠️Примечание переводчика: вышеприведенное предложение сказал он, а не я. Конечно же, Асии нравится играть в этот сет.

Роббин Баау 🇳🇱

Недостатком этого RFC (

В Vue2 есть только API параметров, и в итоге мы получаем классоподобный компонент. Но если бы этот RFC использовался, мы столкнулись бы со следующими вариантами:

  • Options API
  • Class API (требуется плагин)
  • Composition API (vue2 и vue3 пишутся по-разному)
  • сref:синтаксический сахар
  • без синтаксического сахара

Это сделает базу пользователей очень фрагментированной, что затруднит новичкам и людям, испытывающим трудности с выбором. Было бы намного проще, если бы вам просто нужно было помнить: «Если вы хотите быть реактивным, используйте API параметров и используйте API композиции для логического повторного использования».

Но, судя по всему, этот «магический» синтаксис нравится многим. Если кто-то предложит пользовательскую грамматику, возможно, он захочет расширить ее в будущем.Можно ли реализовать ее в сторонней библиотеке, отличной от Vue? Если это основной синтаксис Vue, его необходимо будет поддерживать в будущих версиях Vue.

я думаю, что это$Очень запутанно: если вы не совсем понимаете$Причина и следствие приставки, я думаю, это будет очень запутанно! То есть вам нужно знать фактическое значение ссылки, и вам нужно знать, что вы имеете дело с ссылкой, которая синтаксически подслащена, и в этом случае вам нужно добавить$префикс, а в остальных случаях префикс не требуется. Я твердо верю, что это вызовет много проблем для многих пользователей.

Ю Юси (ответ)

Вы говорите слишком преувеличенно.

Class API — это официальный плагин, но просто плагин. Не является частью основного API, а только для пользователей, отдающих предпочтение Class . Другими словами, это не «мейнстрим».

⚠️Примечание переводчика: если это не мейнстрим, то это не非主流?

Цель Composition API для vue2 и vue3 одинакова, и по крайней мере большая часть, если не весь код выглядит одинаково. Незначительные технические различия не рассматривают их как «два способа сделать одно и то же».

Код Composition API, написанный без синтаксического сахара, на 100% идентичен обычному использованию Composition API, как это предлагается в RFC (За исключением того, что нет необходимости вручную возвращать все). На самом деле, я не вижу причин не использовать новый

Вам не кажется, что лучше написать так:

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

ref:является чистым синтаксическим сахаром. Это не меняет того, как API композиции работает внутри . Если вы уже понимаете Composition API, то поймитеref:Синтаксический сахар не займет больше 10 минут.

Подводя итог - есть две "парадигмы": (1) API опций (2) API композиции setup> иref:Синтаксический сахар — это не другой API или парадигма. Это просто расширения Composition API для выражения той же логики с меньшим количеством кода.

(Цитируя то, что только что сказал Робин): ​​Если кто-то предложит пользовательскую грамматику, возможно, он захочет расширить ее в будущем.Может ли она быть реализована в сторонней библиотеке, отличной от Vue?

Итак, вы также согласны с тем, что многие люди хотят использоватьref:Синтаксический сахар, но рекомендуется не поддерживать его во Vue, а вместо этого различным сторонним библиотекам рекомендуется реализовывать собственный синтаксис. Не приведет ли это только к большей фрагментации? Подумайте о CSS-in-JS в экосистеме React.

(цитируя то, что только что сказал Робин): ​​Я думаю, что это$Очень запутанно: если вы не совсем понимаете$Причина и следствие приставки, я думаю, это будет очень запутанно! То есть вам нужно знать фактическое значение ссылки, и вам нужно знать, что вы имеете дело с ссылкой, которая синтаксически подслащена, и в этом случае вам нужно добавить$префикс, а в остальных случаях префикс не требуется. Я твердо верю, что это вызовет много проблем для многих пользователей. .

$foo 其实就代表 fooподобноfoo 就代表 foo.value. Это действительно так запутанно? Какую конкретную проблему это вызывает? забывать$Когда он был добавлен? Обратите внимание, что даже без синтаксического сахара мы часто забываем, когда использовать .value, последнее, скорее всего, произойдет.

Вы просите пользователей отказаться от преимуществ Composition API, потому что вам не нравится синтаксический сахар, который делает Composition API менее подробным. Я действительно не думаю, что это имеет смысл.

ЛинусБорг 🇩🇪

Если теперь предоставляет переменные верхнего уровня непосредственно шаблону

Как это будет обрабатывать промежуточные переменные:

const store = inject('my-store')

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

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

Даже если переменную хранилища не нужно предоставлять для

Недостаток: это сделает сгенерированный код больше, так как он сделает объект, возвращаемый настройками, больше, и мы потеряем некоторую «ясность» того, что предоставляет шаблон.

С положительной стороны, можно возразить, что явное определение того, что предоставляется шаблонам, слишком громоздко, и кажется, что

Ю Юси (ответ)

Да, все переменные верхнего уровня доступны. Технически, если мы объединим это, мы также можем ввести другой режим компиляции шаблона, в котором мы возвращаем функцию рендеринга непосредственно из установки. Это делает область видимости более прямой и позволяет избежать прокси-рендеринга.

Элеф (iNerV 🇷🇺)

Это очень плохо. Я не хочу видеть svelte во Vue. (не хочу видеть незаконный синтаксис js)

Суммировать

Вообще говоря, большинство тех, кто придерживается противоположных взглядов, такие же, как и в Китае, но интересно видеть, что здесь так много людей разных национальностей обсуждают, но очень мало голосов из Китая 🇨🇳, и это плохо видно тот все еще находится в Гонконге 🇭🇰, вы также можете зайти на GitHub, чтобы напрямую пообщаться с учеными-конфуцианцами.

Конечно, не используйте китайский язык, ведь вы хотите, чтобы его понимали люди всех национальностей (По крайней мере, я его почти не понимаю. Я перевел голландскому мальчику английский язык, и я не думаю, что он говорит очень хорошо. Наш английский не хуже, чем их.), представьте, как бы мы поняли, если бы эти люди говорили на своем родном языке. Принуждение к использованию китайского удобно для моих соотечественников, но приведет к дальнейшему падению нашей международной репутации.

Когда вы идете на GitHub для обсуждения, вы должны сделать все возможное, чтобы сохранить имидж нашей страны в мире!

Эта статья была впервые опубликована в публичном аккаунте:«Фронтальное обучение не движется»

Замечательные статьи в прошлом

Категории