Recentemente, o autor do VUE, You Yuxi, apresentou uma proposta para o açúcar sintático Ref na RFC , o que causou polêmica na comunidade.
Resumidamente, esta proposta apresenta um novo método de escrita de tag de script no Single File Component (SFC) <script setup>, que é escrito de forma a expor automaticamente todas as declarações de variáveis de nível superior para o modelo. Ao mesmo tempo, <script setup>ele introduziu um açúcar sintático para eliminar o valor do atributo ref do açúcar sintático automaticamente para o código normal durante a compilação.
Por exemplo, este código HTML:
<script setup>
// Declara uma variável que será compilada para ref
ref: count = 1
function inc () {
// Esta variável pode ser usada como um valor normal sem .value
count ++
}
// Use o prefixo $ para corresponder ao original objeto ref
console.log ($ count.value)
</script>
<template>
<button @ click = "inc"> {{count}} </button>
</ templat
Será compilado assim:
<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>
</ templ
Observe que label: x = 1 ainda é uma sintaxe JS válida (ou seja, uma instrução de atribuição rotulada é equivalente a atribuir diretamente um valor a x, e um erro será relatado se x não for definido no modo estrito), que é equivalente ao processamento especial da semântica de nomes de rótulos ref.
Por que você quer fazer isso?
Sra. Yu Xi disse que, por um lado, pela exposição automática variável de nível superior pode reduzir a redundância de código, por outro lado, por meio da ref:gramática pode tornar mais eficiente ref.
Desde o nascimento da Composition API, todos discutem se é melhor usar objetos ref ou reativos. Usar ref fará com que o código esteja em todos os lugares .value, e se os desenvolvedores não usarem o TypeScript, eles muitas vezes perderão a escrita .value, então muitos desenvolvedores não sabem como lidar com ref.
Na verdade, ref existe porque existem alguns problemas com a linguagem JS: se você não encapsular um valor em um objeto, não pode transformar esse valor em um dado responsivo por meio do próprio método JS. Isso significa que se a semântica de JS não for alterada, é impossível usar ref como variáveis comuns. Além disso, You Yuxi também admitiu que foi inspirado pela estrutura Svelte. Svelte mudou a semântica do JS anteriormente, export let $e Svelte deu-lhe funções mais poderosas e convenientes.
"No passado, queríamos manter a semântica original do JS o mais inalterada possível, porque mudanças mágicas no JS trariam alguns problemas, mas sempre há uma necessidade de ter o" primeiro a comer caranguejos "para transformar JS para fornecer aos desenvolvedores um melhor desenvolvimento Experiência. "Você disse Yuxi.
Causar polêmica
Em resposta a esta proposta, muitos usuários da comunidade expressaram sua oposição a esta proposta. O motivo da oposição da maioria das pessoas é que esta proposta é muito séria para mudanças mágicas do JavaScript. Eles questionam por que a sintaxe de tag é usada em vez de inventar diretamente uma nova sintaxe, o que aumenta a carga mental dos usuários. e muitos mais.
Em resposta a essas perguntas, o próprio You Yuxi respondeu um por um:
Sobre Magic Change JavaScript
ref: count = 1 usa sintaxe de tag, que é JavaScript legal no nível de sintaxe, e pode ser executado normalmente no modo não estrito, até mesmo a semântica declara uma variável global chamada count. Ao mesmo tempo, esta também é uma gramática TypeScript válida e não será confundida com declarações de tipo (as declarações de tipo devem necessariamente exigir let e const)
Claro, esses são apenas os aspectos legais da gramática, na verdade, equivalem ao
ref:rótulo dado a uma semântica diferente. A sintaxe da tag em si é um recurso raramente usado, o uso real para marcação também é declarado ciclo (usado / frente enquanto para), como exemplosref: count = 1de tal uso, o que é semântica original inútil, é por isso Acreditamos que sacrificar essa semântica primitiva para obter declarações de variáveis reativas é uma troca que vale a pena.
Por que usar sintaxe de tag em vez de inventar diretamente uma nova sintaxe
O uso da sintaxe de tag é realmente inspirado em Svelte. O motivo fundamental é que manter a compatibilidade completa com JS no nível de sintaxe pode garantir o encaixe ecológico das ferramentas JS existentes, tanto quanto possível. A sintaxe do rótulo pode ser suportada diretamente por Babel, analisador / transformador TS (como esbuild / swc), Prettier, ESLint e qualquer destaque de sintaxe JavaScript IDE, apenas quando a semântica estiver envolvida, como dedução de tipo e regras relacionadas à variável ESLint Só precisa de compatibilidade direcionada. Se uma nova sintaxe não padrão for usada, significa que todas as ferramentas acima precisam ser modificadas no nível do analisador, o que basicamente não é viável.
Eu sinto que o fardo mental ficou mais pesado
Embora a camada inferior seja um açúcar sintático compilado para ref (), na verdade, os novatos não precisam saber a existência de ref () antes de poder usá-lo, porque no cenário em que o objeto ref subjacente não precisa ser obtido, a variável mind declarada por ref: O modelo é exatamente igual ao modelo mental das variáveis declaradas com let. O usuário só precisa tratar ref: como um let responsivo. Este modelo é suficiente para realizar a maioria das funções de nível de entrada.Apenas quando você começa a aprender a extração e reutilização de lógica após o avançado, é necessário conhecer o conceito de ref ().
Para os usuários que já estudaram a API de composição, eles sentirão que “mais um conceito foi adicionado.” Ao mesmo tempo, como a RFC discute as regras de compilação em detalhes, haverá uma ilusão de “aumento da carga mental”. Na verdade, quando usei CoffeeScript, Babel ou TS há muito tempo, também me senti assim, porque gosto de ver como fica antes de usá-lo. O resultado é que, depois de ler isso, usei a gramática de nível superior e não pude deixar de convertê-la para a gramática de nível inferior. Mas isso é essencialmente uma espécie de inércia de nossos cérebros depois de nos acostumarmos com a maneira de pensar subjacente. Esta inércia desapareceu rapidamente depois de usar a nova gramática por um período de tempo, e nossos cérebros ainda são muito adaptáveis. Se você não se importar com o resultado da compilação no início, não haverá esse problema (quando você usa coalescência nula ou decorador, você pensa sobre o resultado da compilação babel / TS?)
Para usuários que estão começando do zero, como mencionado acima a ref: é apenas um let que pode desencadear uma resposta, e o custo de aprendizagem é muito baixo.
Sua resposta original do Yuxi: https://www.zhihu.com/question/429036806/answer/1564223482
Finalmente, You Yuxi disse que antes da publicação desta proposta RFC, ele sabia que causaria muita controvérsia, e ele entendeu que a primeira reação das pessoas à nova tecnologia era "inaceitável". No entanto, ele também disse que a proposta pode não ser necessariamente implementada. Espero que você seja racional ao discuti-la. Ao mesmo tempo, sugiro que você leia o texto completo da RFC e a discussão no GitHub antes de levantar qualquer dúvida.
RFC completo: https://github.com/vuejs/rfcs/blob/script-setup/active-rfcs/0000-script-setup.md