preface

I don’t like this syntax either, but it’s worth taking a look at the proposal on GitHub to see what the attitude of foreign developers is and whether they share our views. The proposal is RFC 228. But RFC 228 is actually a new proposal to distinguish it from the other proposal, the original proposal was RFC 222, which was eventually split into RFC 227 and RFC 228, so let’s start with RFC 222.

The translation

Especially the rain creek

Introduction to the

  • In a single file component (xxx.vue) introduced a new script type, <script setup>, which automatically exposes all top-level variable declarations to <template> for use.
  • Introduces a compilers based syntax sugar in
  • Note that this proposal is intended to replace the

Basic usage

⚠️ A top-level variable is a variable that is not declared in a block-level scope

<script setup>
// The imported Foo component can be used directly in the template.
import Foo from './Foo.vue'
  
import { ref } from 'vue'

// Write Composition API code just as you would in normal setup(),
// No need to return everything manually
const count = ref(0)
const inc = () = > { count.value++ }
</script>

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

👆 The code above will compile to look like this 👇 :

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

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

    return {
      Foo, // Even if the Foo component is not declared, it counts as a top-level variable
      count,
      inc
    }
  }
}
</script>

<template>
  <Foo :count="count" @click="inc" />
</template>
Copy the code
  1. ref:Syntax sugar makes the code cleaner
<script setup>
// Declare a variable (which will be compiled as a ref)
ref: count = 1

function inc() {
  // This variable can be used just like a normal variable
  count++
}

// If you want to get the original variable, you need to add 💲 before the variable
console.log($count.value)
</script>

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

👆 The code above will compile to look like this 👇 :

<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>
Copy the code

Before commenting:

  • Make sure you have read the entire RFC
  • Please do not simply answer “I like/I don’t like “- it will not contribute meaningfully to the discussion.
  • If you do not agree with the proposal, please make specific arguments within the scope of the points presented in the Motivation and drawbacks section. Note that the syntax is tag syntax in JavaScript. We just give different semantics to the ref: tag. This is like writing a Vue directive in HTML.

⚠️ translator’s note: And then there’s the like reply:

Ycmjason 🇬🇧

Just an opinion:

Really don’t like the idea. Too much grammar is being created. And it’s not JavaScript anymore.

Yuyu Creek (reply)

We expect this reaction, and I know it can be controversial, so for any other comments:

  • Make sure you have read the entire RFC
  • Please do not simply answer “I like/I don’t like “- it will not contribute meaningfully to the discussion.
  • If you do not agree with the proposal, please make specific arguments within the scope of the points presented in the Motivation and drawbacks section.

Privatenumber (privatenumber 🇺🇸 🇯🇵)

Does the compiler automatically register all imported XXX.vue files as components?

Specifically, I’m curious how the compiler recognizes what is a Vue component and what is not. If I import a component in the form of XXX.js, will I still be able to use it?

If we are using higher-order components, we may not want the imported higher-order components to be automatically registered as components.

If we want to add custom syntax, can ES2021’s export Default from syntax be implemented?

I think it might be concise and clear:

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

Yuyu Creek (reply)

The compiler can tell by the setup context. The template compiler extracts the binding information from script compile time to determine whether the component is available.

I think importing xxx.vue and wrapping it as a high order component is a very rare case. In this case, you can use a separate regular <script> tag to de-register the component the way you did before.

Will figure (btoo 🇺 🇸)

I’d rather use svelte’s $: than svelte-ref:.

You can also keep access to the original ref by prefixing the variable name with a $.

⚠️ Translator’s note: Svelte is another popular framework abroad, and this proposal was inspired by the way svelte was written

Johnson (Johnsoncodehk 🇭🇰)

⚠️ translator: This person is not 👍, but 👎, let’s not just look at the praise, the high step is also interesting

$: + let/const Like this:

$: let foo = 1 // This variable stands for ref
$: const bar = foo + 1 // This variable represents computed
$: let baz = computed(() = > bar + 1)
Copy the code

It will then compile like this:

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)
Copy the code

I feel like we don’t want to get rid of the js semantics. Of course we could have an approach that is entirely based on js semantics, but is that what we want?

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

It will then compile like this:

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

Like it (👍), don’t like it (👎)

⚠️ Translator: He said that, not me. Sure enough, Asia loves to play this game

(RobbinBaauw 🇳🇱)

The downside of this RFC (<script setup> was itself a drawback, but now it gets worse) is to write a lot of options that do the same thing. Experienced Vue developers (such as the ones commenting on the RFC) know all the options and how they relate to each other, but for the majority of Vue developers, this is not the case.

In Vue2, with only the Options API, we end up with a class-like component. But if we use this RFC, we will be faced with the following choices:

  • Options API
  • Class API (You need a plug-in)
  • Composition API (Vue2 and VUE3 are also written differently)
  • < script setup > collocationref:Syntactic sugar

This will make the user base very fragmented, making it too difficult for beginners and people with choice difficulties. It would be much easier to just remember: “Use the Options API for responsiveness, and use the Composition API for logic reuse.”

But apparently, many people like this “magic” grammar. If someone comes up with a custom syntax that they might want to extend in the future, could it be implemented in a third-party library other than Vue? If this is the core syntax of Vue, it will need to be supported in future Vue releases.

I think the $is very confusing: if you don’t fully understand the antecedent of the $prefix, I think it can be very confusing! In other words, you need to know that this thing is actually a ref, and you also need to know that you’re dealing with a syntactically sweetened ref, in which case you need to prefix it with $, and in other cases you don’t need to prefix it. I’m sure this will cause a lot of problems for many users.

Yuyu Creek (reply)

You’re exaggerating.

The Class API is an official plug-in, but it’s just a plug-in. It is not part of the core API and only appeals to users with a particular preference for Class. In other words, it’s not “mainstream.”

⚠️ translator note: not mainstream that is not mainstream?

The purpose of vuE2 and VUE3’s Composition API is the same, and most, if not all, of the code looks the same. Small technical differences do not treat them as “two ways of doing the same thing.”

As recommended in the RFC, Composition API code written with no syntactic sugar is 100% the same as normal Composition API usage (except that there is no need to return everything manually). In fact, I don’t really see a reason not to use the new

Do you think it would be better to write this:

export default {
  components: {... },setup(){... }}Copy the code

Ref: Pure grammar sugar. It does not change the way the Composition API works in

To sum up – there are two “paradigms” : (1) Options API (2) Composition API

(quoting Robin) : If someone comes up with a custom syntax that they might want to extend in the future, could it be implemented in a third-party library other than Vue?

So, you agree that many people would like to use ref: syntax-sugar, but recommend against supporting it in Vue and encourage various third-party libraries to implement their own syntax-sugar. Doesn’t that just lead to more fragmentation? Think css-in-Js in the React ecosystem.

(To quote Robin) : I think the $is very confusing: if you don’t fully understand the $prefix, I think it will be very confusing! In other words, you need to know that this thing is actually a ref, and you also need to know that you’re dealing with a syntactically sweetened ref, in which case you need to prefix it with $, and in other cases you don’t need to prefix it. I am sure this will cause a lot of problems for many users.

$foo actually stands for foo just like foo stands for foo.value. Is it really that confusing? What are the exact specific problems that this leads to? Forgot when $was added? Note that even without grammatical sugar, we often forget when to use.value, which is more likely to happen.

You’re asking users to forgo the benefits of the Composition API because you don’t like syntactic sugar, which makes the Composition API less verbose. I really don’t think it makes sense.

LinusBorg 🇩🇪

If <script setup> now exposes the top-level variables directly to the <template> template

How would that handle intermediate variables:

const store = inject('my-store')

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

function addState(newState) {
  store.add(newState)
}
Copy the code

The store variable is exposed to the <template> template even if it does not need to be exposed. But is this actually a problem?

On the downside: it makes the generated code bigger, because it makes the object returned by the Settings bigger, and we lose some “clarity” about what the template exposes.

On the plus side, one could argue that it’s too much trouble to explicitly define what’s exposed to templates, and that <template> now feels more like JSX.

Yuyu Creek (reply)

Yes, all the top variables are exposed. Technically, if we merge them, we can also introduce another template compilation mode in which we return a render function directly from setup. This makes the scope more direct and avoids the Render Proxy.

Eleuf (iNerV 🇷🇺)

That’s too bad. I don’t want to see svelte in Vue. (Don’t want to see illegal JS syntax)

conclusion

Generally speaking, there are a majority of people who are against it, which is similar to China. It is interesting to see so many people of different nationalities discussing here, but there are very few voices from China 🇨🇳, and one from Hong Kong 🇭🇰. You can also go to GitHub to have a direct debate with scholars.

Of course, don’t use Chinese, after all, you need to be able to read it by all nationalities (at least barely, I translated the Dutch kid’s English and felt it was not as good as theirs, we are as good as theirs), imagine how we would understand it if they all spoke in their own language. If we forcibly use Chinese, our compatriots may feel comfortable, but it will cause our international reputation to further decline.

When you go to GitHub to discuss or try to maintain our country’s image in the world ha!

The article was published on the official account “Front-end Learning does not Move”.

Previous excellent article

  • Microsoft launches comments section on GitHub
  • Vue 3.0.3: New CSS variable passing and the latest Ref Proposal
  • “Double 11 small black box is cool? Let’s use CSS variables to improve!”
  • “Don’t underestimate how one question can reveal a candidate’s true colors.”
  • “Mobile Layout Interview Questions to test your CSS Skills (Center)”
  • A series of confusing behaviors after setting prototype Objects as Proxies
  • Vue’s Super Fun New Feature: DOM Portal
  • A fun new feature of Vue: Introducing JS variables into CSS
  • Create your own Visual Data Map without any libraries
  • “Use of React’s Super-popular CSS-in-JS Library in the Vue Project: Styled – Components”
  • Is It Finally Vue’s Turn to Inspire React?
  • A Small Pit in Vue3 on IOS
  • Upgrade your React project to Immer instead of Immutable by 2020
  • “Soul Interrogation from the Author of React Hooks and Immutable”
  • Good news, Vue3 official document is available in Chinese!
  • Hooks use of the New VUe-Router
  • Vue 3:20 Years of Status Updates
  • React 17 is officially a transition version!
  • Yu Yuxi: The Design Process of Vue3
  • The Father of Node’s refactoring Deno is finally released. Will it Replace Node after all?
  • The Vue3 beta was released early this morning and openly supports scaffolding!