Два предложения по Vue 3.0 недавно привлекли внимание и обсуждение многих разработчиков. Одно из них — предложение по настройке сценария, а другое — предложение по сахару.
Большинство разработчиков положительно относятся к предложению по настройке скрипта.
В отношении предложения ref-sugar значительное количество разработчиков выразили негативное отношение.
В соответствующих RFC на Github [0] и Zhihu Q&A [1] разработчики дома и за рубежом активно выражали свое мнение. Среди них есть некоторые взгляды и явления, над которыми стоит поразмыслить.
В этой статье мы выберем несколько интересных фрагментов и интерпретируем их.
1. Что на самом деле делает предложение Vue?
Во-первых, давайте посмотрим, что делают два предложения Vue.
Предложение по настройке скрипта состоит в том, чтобы извлечь options.setup на верхний уровень.
Напишите следующее:
<script>
import Foo from './Foo.vue'
import { ref } from 'vue'
export default {
setup() {
const count = ref(1)
const inc = () => { count.value++ }
return {
Foo, // see note below
count,
inc
}
}
}
</script>
<template>
<Foo :count="count" @click="inc" />
</template>
Замените этой более краткой формой:
<script setup>
// imported components are also directly usable in template
import Foo from './Foo.vue'
import { ref } from 'vue'
// write Composition API code just like in a normal setup()
// but no need to manually return everything
const count = ref(0)
const inc = () => { count.value++ }
</script>
<template>
<Foo :count="count" @click="inc" />
</template>
Предложение ref-sugar еще больше упрощает способ написания ref.value.
<script setup>
import Foo from './Foo.vue'
// declaring a variable that compiles to a ref
ref: count = 1
const inc = () => { count++ }
// access the raw ref object by prefixing with $
console.log($count.value)
</script>
<template>
<Foo :count="count" @click="inc" />
</template>
Как показано выше, количество линий Кодекса стало менее лаконичностью под влиянием этих двух предложений.
Это то, что на самом деле делает новое предложение Vue: предоставление синтаксического сахара в файле Vue SFC для оптимизации процесса программирования.
2. Что, по мнению критиков, делает предложение Vue?
Мы извлекаем некоторые интерпретации предложения Vue некоторыми разработчиками во время обсуждения.
1、
请不要再制造更多的 js 方言了
2、
感觉不太靠谱，跟 js 开发者的直觉不一样，容易陷入混乱。
3、
这是一个极其危险的信号
因为修改js语义意味着与生态脱节，而vue的团队说实话还不能自给自足打完一整个生态。
目前来看label语义的修改并不会过多影响，但是会导致开发者对以后vue的生态兼容性产生疑虑从而丢失开发者。
在web的世界里，与标准脱离的，没有一个有好下场，除非倒逼标准，否则没有漏网之鱼。
4、
vue和react都用过一段时间，vue感觉是经常忘记语法，需要对照文档才知道怎么写，react很少需要查阅文档
5、
等过这一套标准越来越复杂，需要重复理解的东西越来越多，并且它并不能给程序员带来深度上的提升，而只是用于写表面的编程的时候，你会发现，这套框架被淘汰了
6、
很不看好，对于动js的语义形成方言这种解决方案应当慎之又慎，为了解决.value的问题是否值得？
7、
别再使用魔法了☹️
8、
想了一整天都没想明白，尤大大会搞出这样子富有争议的rfc。我总觉得使用装饰器会比这个更容易接受…
9、
个人不是很喜欢，违反直觉，不好用。需要增加用户理解成本
3. Небольшое улучшение или большой кризис?
С точки зрения формы кода предложение Vue Ref-sugar является эффективным небольшим улучшением, выражающим ту же логику с более коротким и более совершенным кодом.
Однако концептуально некоторые критики интерпретируют Великий кризис следующим образом:Vue пытается бросить вызов стандартам.
Критики рассматривают Ref-sugar как красный флаг, что Vue собирается уйти от веб-стандартов, что технологический стек делает ставку на то, что Vue больше не безопасен, и что Vue предает свое предыдущее обещание.
Существует огромное отвращение к антистандартному поведению, что вполне понятно.
Front-end инженеры долгие годы были обременены отсутствием совместимости основных браузеров с веб-стандартами. Всякий раз, когда браузер не проявляет активности в соблюдении стандартов и сильно отстает от других браузеров, он будет высмеиваться как: XXX — это новый IE.
Мы надеемся, что все браузеры будут поддерживать веб-стандарты, мы надеемся, что основные фреймворки не создают свой собственный набор игрового процесса, мы надеемся, что под прочным и унифицированным нижним слоем мы хотим сосредоточиться на реализации продукта и решении более важных задач, а не попадание в низкоуровневые задачи совместимой обработки.
Защита стандартов имеет естественную справедливость в области внешнего интерфейса.
Поэтому критики утверждают, что Vue следует улучшать, но при этом соответствовать стандарту.
В-четвертых, решения по стандарту
Здесь мы выбираем несколько кандидатов, которые придумали разработчики, которые соответствуют критериям и которые, по их мнению, также решат проблему.
4.1 Проблема не существует или не требует решения
Некоторые разработчики считают, что ref.value не является проблемой и ее не следует решать.
В частности, если используется язык TypeScript, IDE и редактор грамотно подскажут, что пропусков .value почти не будет, и никакой умственной нагрузки они не ощущают.
Дело в том, что не все пишут код Vue на TypeScript, и не все разработчики не видят проблемы в .value.
4.2. Принять предложение-предложение[2]
Некоторые разработчики искали в JavaScript рефы-предложения и думали, что это может быть решение, которое не только соответствует стандарту, но и помогает Vue решить проблему.
let ref count = 0;
Если вы внимательно посмотрите на предложение offer-refs, вы можете обнаружить, что это совсем не то же самое, что vue-ref. vue-ref — это реактивная ссылка, тогда как предложение Offer-refs описывает привязку ссылок в традиционном смысле. Просто используйте слово ref.
Более того, это предложение-предложение бездействовало несколько лет и не развивалось, оно далеко не стало настоящим стандартом. Не могу решить насущную проблему Vue.
4.3. Принять предложение декораторов[3]
Некоторые разработчики предложили, чтобы в новом предложении декораторов поддерживались декораторы переменных.
То есть объявления переменных можно декорировать и размещать в сцене vue-ref примерно так, как показано ниже.
let @ref count = 0
Выглядит очень привлекательно, как будто проблема успешно решена. но:
Во-первых, она слишком новая, это идея, выдвинутая совсем недавно, и будет ли она реализована и когда будет реализована, совершенно непредсказуемо. Далекая вода не может спасти ближний огонь.
Во-вторых, это несовместимо с семантикой и использованием нескольких текущих предложений декораторов. Как только Vue примет новую версию предложения декоратора, это может означать, что широко используемые в настоящее время декораторы основного стиля нельзя использовать, и возникает конфликт.
В-третьих, это решает только проблему создания части vue-ref, а не частей доступа и обновления.
В чем смысл?
let @ref count = 0
// 访问必须通过 count.value
count.value
// 赋值必须通过 count.value=
count.value += 1
Декоратор просто помогает нам создать ref, но части доступа к ref.value и обновления ref.value отсутствуют.
Предложение-рефы вместе с предложением-декораторами, но могут преодолеть эти трудности. Это становится следующей формулировкой:
let @reactive ref count = 0
Порядок очень важен, сначала станьте реф-объектом, а потом добавляйте реактивную способность, если она следующая, боюсь, не получится:
let ref @reactive count = 0
Он становится ссылкой с {значением: 0}, за которым следует .value.
Жаль, что вышеприведенное предположение представляет собой ситуацию, которая становится еще более вялотекущей при наложении друг на друга двух предложений с малой вероятностью приземления. Трудно ожидать чего-либо.
4.4 Схема соглашения об именах переменных
Некоторые разработчики предложили согласовать имена переменных ref, чтобы пометить переменную как принадлежащую vue-ref.
let countREF = 0
console.log('count', countREF)
countREF += 1
Или упростите свойство .value.
let count = ref(0)
console.log('count', count.$)
count.$ += 1
Хотя это и не является полным решением проблемы, они считают, что это облегчило проблему.
На практике это может сработать, но такой уровень разрешения может не стоить того. Разработчикам по-прежнему постоянно напоминают, что манипулируемые переменные находятся в оболочке ref.
4.5, решение на основе комментариев
Некоторые разработчики предложили пометить переменную как принадлежащую vue-ref с помощью комментария.
// @ref
let count = 0
console.log('count', count)
count += 1
Такой подход вполне разумен: JSDoc использует аннотации для обозначения типов функций и описаний документов и добился успеха.
Однако есть и другая сторона проблемы vue-ref: доступ к объектам ref. Мы не можем наблюдать за примитивным значением, нам нужно следить за реактивным значением.
Таким образом, решения на основе комментариев, даже если они удаляют часть синтаксического сахара в теге ref:, могут нуждаться в сохранении еще одной функции Ref-sugar: $count.
// @ref
let count = 0
watch($count, () => {})
Тем не менее, сама по себе система комментариев — это неполный процесс решения проблемы vue-ref. Это также принесет новые проблемы. Разработчики могут начать часто забывать добавлять метки комментариев. Также большой проблемой является создание новой привычки сначала писать комментарии, а затем писать объявления переменных.
Есть и другие решения, которые не были упомянуты, и большинство из них еще более неиграбельны.
В общем, другие варианты в соответствии с этими стандартами имеют различные недостатки и не решают проблемы vue-ref должным образом.
5. Стандартный состав и эволюция
Вспомните высказывания, критикующие реф-сахар за нарушение норм и стандартов.
Стандарт слова в основном играет роль, в которой нельзя сомневаться, нарушать или обсуждать, и это не ясное лицо.
Все считают стандарты и нормы слишком совершенными.
На самом деле стандарты и нормы не монолитны и не везде бескомпромиссны. Если мы захотим приблизиться к стандартам и спецификациям, мы увидим больше деталей...
5.1 В стандартах и нормах есть элементы, отстающие от времени
Стандарты и спецификации также играют роль документации и обратной совместимости. Особенно такие вещи, как JavaScript, которые на самом деле существуют раньше, а стандарты пишутся позже.
В спецификации ECMAScript нет недостатка в сортировке и описаниях функций языка JavaScript, которые устарели, устарели и больше не рекомендуются. Например, аргументы, с, прототип и т. д.
Поэтому, даже если она соответствует стандартам и нормам, она не обязательно хороша, правильна и соответствует требованиям времени.
5.2 В стандартах и нормах не все одинаково важно
Предложение Vue Ref-sugar на самом деле не изменяет синтаксис JS, а только придает помеченной инструкции новую семантику для объявления объекта vue-ref. Поэтому автор Vue Ю Сяою сказал, что это все еще грамматический код JS.
Затем некоторые разработчики нашли это предложение из спецификации ECMAScript [4]:
15.1.1 Static Semantics: Early Errors
It is a Syntax Error if ContainsDuplicateLabels of StatementList with argument is true.
В этой же области появляются одноименные метки, на уровне Static Semantics они относятся к Syntax Error, то есть синтаксической ошибке.
Поэтому некоторые разработчики считают, что это эффективно опровергает легитимный JS-код, на который претендует Ю Сяою, что подтверждает, что Vue Ref-sugar не только семантически нарушает спецификацию, но и грамматически банкротится, что является полным нарушением нормы и от него следует отказаться. .
Эта точка зрения также может быть несостоятельной.
Потому что статическая семантика — это тоже своего рода семантика [5], просто некоторые ее правила просто описывают грамматическую структуру. Когда Ю Сяою сказал, что ref-sugar по-прежнему является легальным кодом JS, то, что он сказал, является законным, со строгой спецификой, на уровне парсера. Он не пытается выразить какой-либо другой уровень легитимности, такой как статическая семантика.
Он подчеркивал легитимность парсинга JS-кода на уровне среды выполнения такими инструментами и средами выполнения, как Babel, Webpack, TypeScript, ESLint, Prettiter и V8.
Мы не можем опровергнуть человека не опубликовано мнение.
Что еще более важно, инструменты, Babel, Webpack, TypeScript, ESLINT, PRETTITER, V8 и т. д., несмотря на тестирование и проверку, не реализуют функцию статической семантики ContainSduplicateLabels.
Как и выше, в консоли хрома нет проблем с запуском кода, содержащего одноименные метки.
То есть фактически не все части стандартов и норм имеют одинаковое значение на практике. Некоторые безобидные части, многие инструменты и JS-движки не реализованы.
Поэтому не все части стандартов и норм заслуживают одинаковой жесткости.
5.3. Стандарты и спецификации развиваются, и семантика может быть скорректирована
Критики говорят, что ref-sugar изменяет семантику помеченного оператора, что является извращением.
Однако на самом деле в определенном контексте очень естественно, обычно и осуществимо корректировать семантику исходной грамматики.
Язык JavaScript делает это сам — строгий режим.
Код JS в строгом и нестрогом режимах имеет одинаковый синтаксис, но разное семантическое поведение.
Присвоение переменной без объявления эквивалентно присвоению значения глобальной переменной в нестрогом режиме, но в строгом режиме выдается ошибка.
Для одного и того же фрагмента кода стандарты ES3 и ES5 дают разные семантические интерпретации.
Стандарты не статичны, стандарты развиваются и эволюционируют.
Конечно, критики могут продолжать настаивать: ES5 — это новый языковой стандарт по отношению к ES3, только новый языковой стандарт может вносить коррективы, а Vue — всего лишь один из фреймворков в языке JS, он этого делать не может.
Итак, давайте посмотрим на следующий код:
const http = require('http');
const hostname = '127.0.0.1';
const port = 3000;
const server = http.createServer((req, res) => {
res.statusCode = 200;
res.setHeader('Content-Type', 'text/plain');
res.end('Hello World');
});
server.listen(port, hostname, () => {
console.log(`Server running at http://${hostname}:${port}/`);
});
Разработчики, знакомые с Node.js, сразу узнают, что вышеприведенный пример кода node.js — «привет, мир». Какое это имеет отношение к тому, что мы сейчас обсуждаем?
С функциональной точки зрения это верно. Если мы посмотрим на это с точки зрения синтаксиса и семантики JS, ситуация будет иной.
Легко обнаружить, что из исходной семантики JS-кода приведенный выше код должен генерировать 4 глобальные переменные: http, имя хоста, порт, сервер, потому что они объявлены и используются в глобальной области видимости.
Однако на самом деле он работает в node.js и не генерирует вышеуказанные глобальные переменные, они будут обернуты в функцию для выполнения, они представляют собой модуль commonjs, а не простой код JS.
То есть в контексте модуля commonjs семантическое поведение этого JS-кода было изменено с монтирования глобальных переменных в локальные переменные в модуле commonjs.
node.js — это среда выполнения/платформа, это не спецификация языка ES5, она также изменяет семантику/поведение кода JS.
Затем код JS ref: count = 1 имеет некоторые корректировки в своем семантическом поведении в контексте vuejs SFC, В чем, по сути, существенная разница между внесением корректировок в контексте ES5 и Node.js?
Чтобы настроить семантическое поведение кода, новая спецификация языка ES5 может это сделать, и новая платформа Node.js может это сделать, но не может ли это сделать новый фреймворк Vue.js?
Критики могут продолжать сужать сферу его критики: Vue.js может естественным образом корректировать некоторые семантические поведения, а предложение по настройке скрипта корректирует вывод верхнего уровня и выводит его в options.setup, с чем согласны большинство разработчиков. Но независимо от ES5, Node.js или настройки скрипта, все они являются небольшими корректировками исходной семантики, либо сообщением об ошибках, либо переходом от глобальных переменных к локальным переменным.
Однако ref-sugar придает помеченному оператору новую семантику, не имеющую ничего общего с его предыдущей семантикой, что неприемлемо.
5.4 Стандарты и нормы часто отстают от практики
Если разработчики действуют строго в рамках стандартов, технологическое развитие может замедлиться или даже остановиться.
Стандарты и нормы часто отстают от практики. После различных изысканий на практическом уровне было сформировано множество решений с разными формами, но мало отличающихся по сути, и возникла потребность в стандартизации.
Одно из применений инструмента Babel — позволить разработчикам писать новые языковые функции, которые еще не полностью вошли в стандарт на практике, корректировать этап предложения в соответствии с отзывами от фактического использования разработчиками и, наконец, попадать в стандарт. .
То есть, как фронтенд-инженеры, нам изначально разрешено использовать некоторые технические функции, которые не входят в текущую стабильную спецификацию.
Если вы считаете, что предложение Babel — это, по крайней мере, путь к норме, а не Ref-sugar Vue, оно может перейти к противоположной стороне нормы. Так:
Существование языка TypeScript добавляет к JavaScript крылья Type-System, а спецификация ECMAScript ничего не означает для включения в Typed-JS.
Это означает, что использование TypeScript также не является путем к спецификации ECMAScript. Даже сам TypeScript на данный момент не имеет спецификации.
Означает ли это, что для интерфейсных инженеров использование TypeScript также возмутительно и противоречит пути разработки ECMAScript?
Стандарты и спецификации не обязательно предоставляют все инструменты, которые мы хотим.Некоторые из них еще не предоставлены, но они будут предоставлены в будущем.В то же время нам также необходимо использовать нестабильные стандартные функции;некоторые из них не предоставят , и нам нужно искать другие Пути и инструменты, чтобы заменить удовлетворение.
Такое расширенное практическое исследование происходит не только на уровне языка, такого как Babel/TypeScript, но также существует на уровне интерфейсной среды.
Расширения языка React JSX выходят за рамки спецификации ECMAScript. Но это не мешает ему быть популярным во фронтенд-разработке и приносить большую пользу.
Член команды React Себастьян предложил однократное предложение Delimited Continuations with Effect Handlers в 2016 г. Он считает, что эта функция очень ценна для UI Framework, и надеется способствовать ее прогрессу. Но в конце концов предложение закончилось.
Команда React не остановилась и не дождалась стандарта, а решила провести рефакторинг нижнего уровня React, используя архитектуру Fiber, фреймворк взял на себя управление стеками вызовов компонента и смоделировал функцию алгебраических эффектов с помощью различных технических средств. . Впоследствии были представлены новые функции React-Hooks, что также положительно повлияло на развитие других фреймворков, таких как Vue.
В очередной раз стандарты отстали от практики и будут отставать и впредь.
Технологическое развитие требует передовой практики и исследований.Мы должны позволить новым платформам, таким как Node.js, новым языкам, таким как TypeScript, и новым инструментам, таким как Babel/JSX, предоставлять некоторые новые способы использования, а также новые фреймворки или фреймворки, такие как React и Vue. Новые версии, исследуйте их по-новому.
Именно эти новые открытия помогают спецификации указать путь. Знание того, какие шаблоны оказались чрезвычайно ценными.
Таким образом, Vue SFC осуществляет эффективный и безопасный семантический анализ синтаксиса помеченных операторов, что не так ненормально, как все думают.
5.5 Нормы — не единственный источник авторитета
Если мы будем держать наши горизонты открытыми, мы выйдем за рамки JavaScript. Мы можем обнаружить, что спецификация ECMAScript — это просто спецификация на одном из языков.
В этом мире по-прежнему много языков, и у них тоже есть свои преимущества. Их стоит изучить в JavaScript. На самом деле, JavaScript многому научился у других языков.
Итак, в других языках практика Vue Ref-sugar настолько возмутительна?
нет.
Например, переменная соглашения $count также существует в таких языках, как Swift/Kotlin.
struct AlternativeRect {
var origin = Point()
var size = Size()
var center: Point {
get {
let centerX = origin.x + (size.width / 2)
let centerY = origin.y + (size.height / 2)
return Point(x: centerX, y: centerY)
}
set {
origin.x = newValue.x - (size.width / 2)
origin.y = newValue.y - (size.height / 2)
}
}
}
Как и выше, вычисляемое свойство Swift поддерживает сокращенную декларацию установщика [7], то есть вы можете опустить set(value) {} и использовать переменную соглашения newValue для доступа к параметру установки.
Хотя в newValue есть только одна переменная, Vue Ref-sugar может создавать множество $refs в зависимости от количества ref: s. Но это только количественная разница, качественно они одинаковы.
{-# LANGUAGE TemplateHaskell #-}
{-# LANGUAGE NoMonomorphismRestriction #-}
{-# LANGUAGE FlexibleContexts #-}
{-# LANGUAGE MultiWayIf #-}
module ShellCheck.Parser (parseScript, runTests) where
Как и выше, Haskell поддерживает{-# LANGUAGE * #-}синтаксис, добавьте языковые плагины.
Даже некоторые языки, поддерживающие макросы, такие как Rust, уже предоставляют стандартные инструменты для изменения синтаксиса и семантики.
let value = json!({
"code": code,
"success": code == 200,
"payload": {
features[0]: features[1]
}
});
Как и выше, serde_json в rust предоставляет макрос json!, который позволяет разработчикам писать json в коде rust.
let mut doc: DOMTree<String> = html!(
<html>
<head>
<title>"Hello Kitty"</title>
<meta name=Metadata::Author content="Not Sanrio Co., Ltd"/>
</head>
<body>
<h1>"Hello Kitty"</h1>
<p class="official">
"She is not a cat. She is a human girl."
</p>
{ (0..3).map(|_| html!(
<p class="emphasis">
"Her name is Kitty White."
</p>
)) }
<p class="citation-needed">
"We still don't know how she eats."
</p>
</body>
</html>
);
let doc_str = doc.to_string();
Как и выше, typed_html в rust предоставляет макрос html!, который позволяет разработчикам писать структуру тегов html в коде rust.
#[derive(juniper::GraphQLEnum)]
enum Episode {
NewHope,
Empire,
Jedi,
}
Как и выше, можжевельник Rust предоставляет макросы Derive, которые могут помечать перечисление rust, соответствующее перечислению GraphQL.
Этот подход аналогичен упомянутой ранее схеме на основе комментариев. Но независимо от того, основаны ли они на комментариях или на метках, единственная разница заключается в форме.Важно то, что они оба изменяют или улучшают семантику конкретной грамматики посредством разметки.
Мы не можем отказаться от изучения других языков, которые, как было доказано, приносят пользу, только потому, что ECMAScript в настоящее время не предоставляет таких функций, как Language Extension или Macro.
В текущей основной инфраструктуре разработки интерфейса уже есть несколько парсеров и компиляторов, таких как Babel, Webpack, TypeScript, ESLint, Prettiter, V8 и т. д., перечисленных выше, Vue также имеет свой собственный vue-компилятор.
Почти весь наш код обрабатывается посредством нескольких компиляций. Благодаря возможностям цепочки инструментов вполне возможно обеспечить преобразования, аналогичные расширениям языка и свойствам макросов. Плагин Babel, макрос babel, angualr-compiler, vue-compiler и т. д. уже выполняли такую обработку для некоторых шаблонов.
На самом деле, рано или поздно интерфейсный фреймворк постепенно истощит выразительную мощь текущего языка JavaScript, и эффективно решить проблему будет сложно, если вы продолжите копать глубже. Необходимо использовать обработку компилятором. Это именно то, к чему стремится Svelte.Он полностью раскрывает динамизм компилятора.Вместо абстракции во время выполнения он реализует механизм реактивности через преобразование во время компиляции.
React уже давно глубоко вовлечен в абстракцию времени выполнения, а также реализует сложную обработку планирования, такую как параллельный режим. Но все же изучаем возможность автоматического дополнения массива зависимостей useEffect через компилятор.
Конвейерная технология компиляции и рендеринга нового поколения Angular, Ivy, также оптимизирована с помощью технологии компиляции.
Много лет назад сообщество назвало компиляторы новыми фреймворками.
Vue не первый, кто сделал этот шаг. И наоборот, Vue, вероятно, является наиболее разумным из основных фреймворков, выбирая синтаксис помеченных операторов, вдохновленный аналогичным использованием в Svelte. Это уже относительно зрелое соображение по результатам предыдущих исследований.
6. Предложение по этикетке-сахару
Осторожность Vue также отражена в том факте, что Ref-сахар является частным случаем более общего Label-сахара.
Команда Vue глубоко обдумала всеобщее возможное неприятие новой семантики и полна решимости решить проблему удобства использования vue-ref с наименьшими жертвами и минимальными затратами.
Здесь мы можем устроить мозговой штурм, чтобы увидеть, как выглядит более общий Label-сахар.
Например, предоставьте больше меток с разными функциями.
Как и выше, используйте expose: для выражения внешнего вывода компонента, используйте Mounted: для выражения onMounted и используйте unmounted: для выражения onUnmounted.
Метки можно комбинировать, выставить: ref: выражение для вывода ссылки во внешний мир.
Другой пример, используемый в компонентах React:
Как и выше, мы используем state: для выражения useState, effect: для выражения useEffect и callback: для выражения useCallback. Код компонента написан более аккуратно и лаконично.
Это интересная идея, и я лично не отвергаю этот стиль. На мой взгляд, это равносильно усовершенствованию обработки этого модуля commonjs с уровня модуля на уровень функции. В функции выразительная сила функции усиливается за счет ярлыка.
Возможно, какое-то время мы не сможем перейти к вышеуказанному шагу. Vue находится в Ref-сахаре, поэтому стоит сделать небольшой шаг вперед и проверить его.
7. Резюме
Выше в этой статье не сказано, что Vue Ref-сахар должен быть правильным, мы должны его безоговорочно поддерживать.
Вместо этого я хочу подчеркнуть, что методы и дизайн Vue Ref-sugar не так страшны и опасны, как описывают некоторые критики. Кажется, что это скорее маленький шаг, который приходит сам собой. Такой подход и дизайн не редкость в других языках и проектах. Даже в области фронтенда Vue не первый, кто сделал это.
Vue Ref-sugar является добровольным, не принуждая разработчиков использовать его и не запрещая разработчикам использовать их любимые знакомые шаблоны.
Если вы можете найти решение, отвечающее требованиям стандарта, оно, естественно, является лучшим, и вам не нужно рисковать и исследовать его.
Однако, пока мы не найдем это идеальное решение, мы не можем отказаться от оптимизации, которую мы можем понять, остановиться и ничего не делать.
Даже если Vue Ref-sugar окажется неверным маршрутом, он не является необратимым с точки зрения его охвата и того, как с ним обращаться. Все коды Vue Ref-sugar легко группировать и автоматически преобразовывать в исходную форму или вновь обнаруженную форму с помощью codemod.
В то же время мы также должны быть более инклюзивными, позволяя фреймворкам до определенной степени ошибаться. Трудно ожидать идеального фреймворка, который никогда не ошибается, но мы можем ожидать фреймворк роста, который исправляет сам себя.
Для такого необязательного, отзывного, разумного предложения с успешными предыдущими исследованиями я не ожидал, что вызову такое сильное сопротивление и критику.
Я чувствую, что в корне могут быть различия в понимании взаимосвязи между языковыми стандартами и фреймворками.
Возможно, в умах многих разработчиков фреймворк
Например, Vue, React, Angular и Svelte — это несколько фреймворков на языке JS, они принадлежат к подмножеству экосистемы JS и находятся под ограничениями категории JS.
С этой точки зрения Vue Ref-sugar стал вызовом авторитету и тупиком.
Эту точку зрения нельзя назвать полностью ошибочной, но она скорее односторонняя.
Фреймворк на самом деле является более широким определением, чем мы думаем, таким же большим, как: фреймворк > язык.
Фреймворк ориентирован на предметно-ориентированные решения, и все языки и инструменты являются его средствами выбора.
Иногда он выбирает язык в качестве основного инструмента, и даже все сопутствующее программное обеспечение реализовано на этом же языке. Но это не значит, что язык выше рамок.
С точки зрения Vue, JS — это всего лишь один из выбранных языков среды выполнения, а для Vue 3.0 уже выбран язык написания TypeScript. В будущем Vue можно будет писать на других языках, запускать на платформах Web/Node.js и запускать на других нативных платформах с помощью compile-to-js или WASM.
HTML, CSS и пользовательский синтаксис шаблона также используются в Vue. Веб-разработка сама по себе является моделью многоязычного сотрудничества, и трудно сказать, что какой-либо язык лучше кого-либо.
Среди них JavaScript — лишь один из языков. Vue выбирает его для написания кода, когда JS может хорошо решить проблему. Vue выбирает TS, когда TS лучше решает проблему.
Vue выбирает необработанную семантику, когда необработанная семантика JS может работать хорошо. Vue предпочитает улучшать семантику помеченных операторов операторов, когда семантика, расширенная с помощью JS, может помочь.
Vue сталкивается с проблемами предметной области разработки пользовательского интерфейса.Это не дочерняя компания JS, но JS является одним из инструментов и средств, которые он использует для решения проблем предметной области.
С этой точки зрения предложение Vue Ref-sugar стало естественным.
Для решения проблемы все технологии и инструменты, включая JS/TS/Template, настраиваются. Ключ, чтобы увидеть, стоимость и выгода.
Пока выгоды превышают или даже намного превышают затраты в долгосрочной перспективе, это решение доступно.
Если критики готовы внимательно прочитать объяснения и ответы Ю Сяою и понять их с точки зрения затрат и выгод, легко обнаружить, что выбор утверждения ярлыка — это прагматичный подход, который полностью учитывает затраты на адаптацию цепочки инструментов, затраты на обучение и использование. стоит выбрать.
Авторы фреймворков ближе к разработчикам, чем те, кто пишет стандарты и спецификации, и больше заботятся о требованиях разработчиков.
Требования разработчиков сначала воспринимаются авторами фреймворка, а затем те, кто пишет стандарты и спецификации, должны общаться и сотрудничать с авторами фреймворка, чтобы предоставить новые функции, которые могут удовлетворить последующие потребности разработки фреймворка.
Функции, которые отчаянно нужны фреймворку, и даже напрямую вносят код в восходящий поток (например, Facebook вносит код в Google Chrome, который реализует API isInputPending, требуемый фреймворком React).
Для нас имеет больше смысла доверять честным и ответственным авторам фреймворков, чем преклоняться перед стандартами и нормами.
Теперь еще раз посмотрите на предложение Vue Ref-sugar, интересно, есть ли другой опыт :-)
[0] New script setup and ref sugar
[1] Как оценить предложение Vue по синтаксическому сахару ref?
[2] proposal-refs
GitHub.com/ не может распознать открытие, о, ты/ лжешь...
[3] Decorators: A New Proposal
slides.com/Pan Zuren Ah Q/deco…
[4] ECMAScript® 2021 Language Specification
Смена работы 39. Умер от голода/код ЕС 262/#цвет…
[5] Wiki: Static Semantics
En.wikipedia.org/wiki/pro с РА…
[6] One-shot Delimited Continuations with Effect Handlers
ES обсудить.org/topic/one - да…
[7] Swift: Shorthand Setter Declaration