From 96c72ff90e91dbbdba2e587c33fd0cc5b3ad2d32 Mon Sep 17 00:00:00 2001
From: Evan You <yyx990803@gmail.com>
Date: Mon, 29 Jun 2020 15:57:59 -0400
Subject: [PATCH 01/20] sfc improvements

---
 active-rfcs/0000-sfc-component-sugar.md | 128 +++++++++++
 active-rfcs/0000-sfc-script-setup.md    | 278 ++++++++++++++++++++++++
 active-rfcs/0000-sfc-style-variables.md |  82 +++++++
 3 files changed, 488 insertions(+)
 create mode 100644 active-rfcs/0000-sfc-component-sugar.md
 create mode 100644 active-rfcs/0000-sfc-script-setup.md
 create mode 100644 active-rfcs/0000-sfc-style-variables.md

diff --git a/active-rfcs/0000-sfc-component-sugar.md b/active-rfcs/0000-sfc-component-sugar.md
new file mode 100644
index 00000000..ebafc46b
--- /dev/null
+++ b/active-rfcs/0000-sfc-component-sugar.md
@@ -0,0 +1,128 @@
+- Start Date: 2020-06-29
+- Target Major Version: 2.x & 3.x
+- Reference Issues: N/A
+- Implementation PR: N/A
+
+# Summary
+
+Syntax sugar for reducing component import and registration boilerplate in Single File Components.
+
+# Basic example
+
+```html
+<component src="./Foo.vue"/>
+
+<template>
+  <Foo/>
+</template>
+```
+
+# Motivation
+
+Currently in SFCs you have to import a component and then pass it to the `export default { components: { ... } }` hash, which leads to a lot of redundancy: for a single component we are repeating its name 3 times: in the imported binding, the file name, and the components option.
+
+The `<component/>` sugar requires the name of each component to be specified only once.
+
+# Detailed design
+
+## Normal Components
+
+**Before**
+
+```html
+<template>
+  <Foo/>
+</template>
+
+<script>
+import Foo from './Foo.vue'
+
+export default {
+  components: {
+    Foo
+  }
+}
+</script>
+```
+
+**After**
+
+```html
+<component src="./Foo.vue"/>
+
+<template>
+  <Foo/>
+</template>
+```
+
+## Async Components
+
+**Before**
+
+```html
+<template>
+  <Foo/>
+</template>
+
+<script>
+import { defineAsyncComponent } from 'vue'
+
+export default {
+  components: {
+    Foo: defineAsyncComponent(() => import('./Foo.vue'))
+  }
+}
+</script>
+```
+
+**After**
+
+```html
+<component async src="./Foo.vue" />
+
+<template>
+  <Foo/>
+</template>
+```
+
+## Component Renaming
+
+By default, the component's locally registered name is inferred from its filename. But they can be renamed locally:
+
+```html
+<component src="./Foo.vue" as="Bar" />
+
+<template>
+  <Bar/>
+</template>
+```
+
+# Drawbacks
+
+This would require updates in tools that parse SFC content for template analysis - e.g. Vetur & `@vuedx`.
+
+However, since this information is going to be provided directly by `@vue/compiler-sfc` in the parsed SFC descriptor, it should remove some extra complexity from these tools as well.
+
+# Alternatives
+
+We considered implicitly registering imported components:
+
+```html
+<template>
+  <Foo/>
+</template>
+
+<script>
+import Foo from './Foo.vue'
+</script>
+```
+
+However, this approach has a few issues:
+
+- `Foo` is unused in the script scope, making it annoying when using linter rules that check for unused variables.
+
+- The only safe assumption about an import being a Vue component is the `.vue` extension, which makes it unable to support components authored in non-SFC formats (e.g. `import Foo from './Foo/ts'` can be a component but we can't really be sure).
+
+# Adoption strategy
+
+This is a fully backwards compatible new feature. However, we probably want to warn users against mixing the manual imports and `<component>` tags so that tools that rely on the extracted information can make safer assumptions.
diff --git a/active-rfcs/0000-sfc-script-setup.md b/active-rfcs/0000-sfc-script-setup.md
new file mode 100644
index 00000000..5f4acd01
--- /dev/null
+++ b/active-rfcs/0000-sfc-script-setup.md
@@ -0,0 +1,278 @@
+- Start Date: 2020-06-29
+- Target Major Version: 2.x & 3.x
+- Reference Issues: N/A
+- Implementation PR: N/A
+
+# Summary
+
+Introduce a compile step for `<script setup>` to improve the authoring experience when using the Composition API inside Single File Components.
+
+# Basic example
+
+```html
+<template>
+  <button @click="inc">{{ count }}</button>
+</template>
+
+<script setup>
+import { ref } from 'vue'
+
+export const count = ref(0)
+export const inc = () => count.value++
+</script>
+```
+
+# Motivation
+
+When authoring components using the Composition API, very often `setup` is the only option that's being used. This results in some unnecessary boilerplate:
+
+```js
+import { ref } from 'vue'
+
+export default {
+  setup() {
+    const count = ref(0)
+    const inc = () => count.value++
+
+    return {
+      count,
+      inc
+    }
+  }
+}
+```
+
+In addition, one of the most often complained about aspect of the Composition API is the necessity to repeat all the bindings that need to be exposed to the render context using a return object.
+
+This RFC introduces a compiler-powered alternative for the usage of `<script>` inside SFCs that greatly reduces the amount of boilerplate:
+
+```diff
+import { ref } from 'vue'
+
+-export default {
+-  setup() {
+-    const count = ref(0)
++export const count = ref(0)
+-    const inc = () => count.value++
++export const inc = () => count.value++
+
+-    return {
+-      count,
+-      inc
+-    }
+-  }
+-}
+```
+
+# Detailed design
+
+When a `<script>` tag in an SFC has the `setup` attribute, it is compiled so that the code runs in the context of the `setup()` function of the component. All ES module exports are considered values to be exposed to the render context and included in the `setup()` return object.
+
+## Using `setup()` arguments
+
+The following equivalent of `setup()` arguments are implicitly available inside `<script setup>`:
+
+- `$props`
+- `$attrs`
+- `$slots`
+- `$emit`
+
+The example code
+
+```js
+import { watchEffect } from 'vue'
+
+watchEffect(() => console.log($props.msg))
+$emit('foo')
+```
+
+would be compiled into:
+
+```js
+import { watchEffect } from 'vue'
+
+export default {
+  setup($props, { emit: $emit }) {
+    watchEffect(() => console.log($props.msg))
+    $emit('foo')
+    return {}
+  }
+}
+```
+
+## Declaring props or additional options
+
+One problem with `<script setup>` is that it removes the ability to declare other component options, for example `props`. We can solve this by checking a special export, `$options`:
+
+```vue
+<script setup>
+import { computed } from 'vue'
+
+export const $options = {
+  props: {
+    msg: String
+  }
+}
+
+export const computedMsg = computed(() => $props.msg + '!!!')
+</script>
+```
+
+This will compile to:
+
+```js
+import { computed } from 'vue'
+
+const $options = {
+  props: {
+    msg: String
+  },
+  inheritAttrs: false
+}
+
+export default {
+  ...$options,
+  setup($props) {
+    const computedMsg = computed(() => $props.msg + '!!!')
+
+    return {
+      computedMsg
+    }
+  }
+}
+```
+
+## With TypeScript
+
+`<script setup>` should just work with TypeScript in most cases. To make implicitly injected variables like `$props` and `$emit` work with proper types, simply declare them:
+
+```vue
+<script setup lang="ts">
+import { computed } from 'vue'
+
+// declare props using TypeScript syntax
+// this will be auto compiled into runtime equivalent!
+declare const $props: {
+  msg: string
+}
+
+export const computedMsg = computed(() => $props.msg + '!!!')
+</script>
+```
+
+The above will compile to:
+
+```vue
+<script lang="ts">
+import { computed, defineComponent } from 'vue'
+
+type __$props__ = { msg: string }
+
+export default defineComponent({
+  props: (['msg'] as unknown) as undefined,
+  setup($props: props__) {
+    const computedMsg = computed(() => $props.msg + '!!!')
+
+    return {
+      computedMsg
+    }
+  }
+})
+</script>
+```
+
+- Runtime props declaration is automatically generated from TS typing to remove the need of double declaration and still ensure correct runtime behavior. (It is force casted into `undefined` to ensure the user provided type is used in the emitted code)
+
+- The emitted code is still TypeScript with valid typing, which can be further processed by other tools.
+
+# Drawbacks
+
+This is yet another way of authoring components, and it requires understanding the Composition API first.
+
+# Adoption strategy
+
+This is a fully backwards compatible new feature.
+
+
+# Unresolved Questions
+
+## Magic `let` bindings
+
+It is technically possible to compile `let` bindings in a way so that root level `let` bindings are implicitly reactive:
+
+```vue
+<script setup>
+export let count = 0
+
+export function increment() {
+  count++
+}
+</script>
+```
+
+can be compiled into:
+
+```vue
+<script>
+import { reactive } from 'vue'
+
+export default {
+  setup() {
+    const __ctx__ = shallowReactive({})
+    __ctx__.count = 0
+
+    function increment() {
+      __ctx__.count++
+    }
+
+    return Object.assign(__ctx__, {
+      increment
+    })
+  }
+}
+</script>
+```
+
+This makes the code even more succinct and removes the need to use `ref` in the root scope of the component. However, this may be a bit too magical and there are a number of consistency issues if we enable this behavior:
+
+- Objects are not implicitly reactive:
+
+  ```js
+  export const state = { count: 0 }
+
+  export function increment() {
+    // doesn't work
+    state.count++
+  }
+  ```
+
+  Making root scope objects deeply reactive by default can lead to potential performance problems, since the user may declare a 3rd party object of unknown size.
+
+- Doesn't work inside nested functions:
+
+  ```js
+  function useFeature() {
+    // not reactive, since it's not root level
+    let count = 1
+    const inc = () => count++
+
+    return {
+      count,
+      inc
+    }
+  }
+  ```
+
+  If we also compile functions inside `<script setup>`, then composition functions inside and outside SFCs will behave *very* differently and the mental model is no longer consistent. It also creates friction for extracting reusable functions out of components.
+
+- Dependency tracking no longer explicit:
+
+  ```js
+  export let count = 0
+
+  watchEffect(() => console.log(count))
+  ```
+
+  By looking at the `watchEffect` callback alone, it is not immediately clear whether it tracks any dependencies at all. We will now need to check if a variable is declared via root level `let` to be sure.
+
+Given the above considerations, magical `let` bindings is not a part of the proposed features of this RFC, but it's discussed here to provide context on why we chose not to include it.
diff --git a/active-rfcs/0000-sfc-style-variables.md b/active-rfcs/0000-sfc-style-variables.md
new file mode 100644
index 00000000..2519ec72
--- /dev/null
+++ b/active-rfcs/0000-sfc-style-variables.md
@@ -0,0 +1,82 @@
+- Start Date: 2020-06-29
+- Target Major Version: 2.x & 3.x
+- Reference Issues: N/A
+- Implementation PR: N/A
+
+# Summary
+
+Support injecting component-state-driven CSS variables into Single File Components styles.
+
+# Basic example
+
+```html
+<template>
+  <div class="text">hello</div>
+</template>
+
+<script>
+export default {
+  data() {
+    return {
+      color: 'red'
+    }
+  }
+}
+</script>
+
+<style :vars="{ color }">
+.text {
+  color: var(--color);
+}
+</style>
+```
+
+# Motivation
+
+Vue SFC styles provide straightforward CSS collocation and encapsulation, but it is purely static - which means up to this point we have no capability of dynamically updating the styles at runtime based on the component's state.
+
+Now with [most modern browsers supporting native CSS variables](https://caniuse.com/#feat=css-variables), we can leverage it to easily connect the component's state and styles.
+
+# Detailed design
+
+The `<style>` tag in an SFC now supports a `:vars` binding, which accepts an expression for the key/values to inject as CSS variables. The expression must be an object literal and cannot contain computed keys (the compiler will warn such cases - see reasoning in the next section). Other than that, it is evaluated in the same context as expressions inside `<template>`.
+
+The variables will be applied to the component's root element as inline styles. In the above example, given a `:vars` binding that evaluates to `{ color: 'red' }`, the rendered HTML will be:
+
+```html
+<div style="--color:red" class="text">hello</div>
+```
+
+## Usage with `<style scoped>`
+
+When `:vars` is used with `<style scoped>`, we need to make sure the CSS variables do not leak to descendent components or accidentally shadow CSS variables higher up the DOM tree. The applied CSS variables will be prefixed with the component's scope ID:
+
+```html
+<div style="--v-6b53742-color:red" class="text">hello</div>
+```
+
+Similarly, CSS variables inside `<style>` that matches the keys in the `:vars` expression will also be rewritten accordingly. This is also why we require the `:vars` expression to be an object literal with no computed keys.
+
+# Alternatives
+
+## Auto Detect Variables
+
+One of the considered alternatives is auto detecting variables to inject using a naming convention:
+
+```html
+<style>
+.text {
+  color: var(--v-color);
+}
+</style>
+```
+
+However, this has a few disadvantages:
+
+- Intention is less explicit;
+
+- Requires a full PostCSS parse first to extract matching variables before the main script can be processed. With `:vars` being declared on the `<style>` tag, the compiler can process the `<script>` part without parsing the CSS at all.
+
+# Adoption strategy
+
+This is a fully backwards compatible new feature. However, we should make it clear that it relies on native CSS variables so the user needs to be aware of the browser support range.

From 390e0a2076ed5054aff4fc259579643d0c6d0891 Mon Sep 17 00:00:00 2001
From: Evan You <yyx990803@gmail.com>
Date: Mon, 29 Jun 2020 16:11:38 -0400
Subject: [PATCH 02/20] improve component sugar example

---
 active-rfcs/0000-sfc-component-sugar.md | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/active-rfcs/0000-sfc-component-sugar.md b/active-rfcs/0000-sfc-component-sugar.md
index ebafc46b..59b6beb8 100644
--- a/active-rfcs/0000-sfc-component-sugar.md
+++ b/active-rfcs/0000-sfc-component-sugar.md
@@ -11,9 +11,13 @@ Syntax sugar for reducing component import and registration boilerplate in Singl
 
 ```html
 <component src="./Foo.vue"/>
+<component async src="./Bar.vue"/>
+<component src="./Baz.vue" as="Qux" />
 
 <template>
   <Foo/>
+  <Bar/>
+  <Qux/>
 </template>
 ```
 

From 22bfdc8b638298eb81286df1e1b10089110f40eb Mon Sep 17 00:00:00 2001
From: Evan You <yyx990803@gmail.com>
Date: Mon, 29 Jun 2020 16:29:12 -0400
Subject: [PATCH 03/20] fix example consistency

---
 active-rfcs/0000-sfc-script-setup.md | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/active-rfcs/0000-sfc-script-setup.md b/active-rfcs/0000-sfc-script-setup.md
index 5f4acd01..a7b2ab69 100644
--- a/active-rfcs/0000-sfc-script-setup.md
+++ b/active-rfcs/0000-sfc-script-setup.md
@@ -111,7 +111,8 @@ import { computed } from 'vue'
 export const $options = {
   props: {
     msg: String
-  }
+  },
+  inheritAttrs: false
 }
 
 export const computedMsg = computed(() => $props.msg + '!!!')

From d805c9ba8ef38cc8d45f7c0a4481b34e1a97b22d Mon Sep 17 00:00:00 2001
From: Evan You <yyx990803@gmail.com>
Date: Mon, 29 Jun 2020 16:47:36 -0400
Subject: [PATCH 04/20] fix example

---
 active-rfcs/0000-sfc-script-setup.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/active-rfcs/0000-sfc-script-setup.md b/active-rfcs/0000-sfc-script-setup.md
index a7b2ab69..2a147d7c 100644
--- a/active-rfcs/0000-sfc-script-setup.md
+++ b/active-rfcs/0000-sfc-script-setup.md
@@ -171,7 +171,7 @@ type __$props__ = { msg: string }
 
 export default defineComponent({
   props: (['msg'] as unknown) as undefined,
-  setup($props: props__) {
+  setup($props: __$props__) {
     const computedMsg = computed(() => $props.msg + '!!!')
 
     return {

From 2d94fbf144e4f68b46506b8e364984b830bfb07a Mon Sep 17 00:00:00 2001
From: Evan You <yyx990803@gmail.com>
Date: Mon, 29 Jun 2020 16:50:31 -0400
Subject: [PATCH 05/20] fix typo

---
 active-rfcs/0000-sfc-component-sugar.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/active-rfcs/0000-sfc-component-sugar.md b/active-rfcs/0000-sfc-component-sugar.md
index 59b6beb8..2fe0b737 100644
--- a/active-rfcs/0000-sfc-component-sugar.md
+++ b/active-rfcs/0000-sfc-component-sugar.md
@@ -125,7 +125,7 @@ However, this approach has a few issues:
 
 - `Foo` is unused in the script scope, making it annoying when using linter rules that check for unused variables.
 
-- The only safe assumption about an import being a Vue component is the `.vue` extension, which makes it unable to support components authored in non-SFC formats (e.g. `import Foo from './Foo/ts'` can be a component but we can't really be sure).
+- The only safe assumption about an import being a Vue component is the `.vue` extension, which makes it unable to support components authored in non-SFC formats (e.g. `import Foo from './Foo.ts'` can be a component but we can't really be sure).
 
 # Adoption strategy
 

From 391a10c1c709dddd0f150d942c187f9bbb7fe9ed Mon Sep 17 00:00:00 2001
From: Evan You <yyx990803@gmail.com>
Date: Tue, 30 Jun 2020 12:41:19 -0400
Subject: [PATCH 06/20] make it clear let bindings are not part of the RFC

---
 active-rfcs/0000-sfc-script-setup.md | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/active-rfcs/0000-sfc-script-setup.md b/active-rfcs/0000-sfc-script-setup.md
index 2a147d7c..89e465f8 100644
--- a/active-rfcs/0000-sfc-script-setup.md
+++ b/active-rfcs/0000-sfc-script-setup.md
@@ -199,6 +199,8 @@ This is a fully backwards compatible new feature.
 
 ## Magic `let` bindings
 
+> Note: This section is not a part of this RFC but included here merely for reference.
+
 It is technically possible to compile `let` bindings in a way so that root level `let` bindings are implicitly reactive:
 
 ```vue

From 923348ce72fd96fe8801f78357e4d57bf176fd78 Mon Sep 17 00:00:00 2001
From: Evan You <yyx990803@gmail.com>
Date: Tue, 30 Jun 2020 12:46:54 -0400
Subject: [PATCH 07/20] use export default for options

---
 active-rfcs/0000-sfc-script-setup.md | 12 ++++--------
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/active-rfcs/0000-sfc-script-setup.md b/active-rfcs/0000-sfc-script-setup.md
index 89e465f8..4f68e98f 100644
--- a/active-rfcs/0000-sfc-script-setup.md
+++ b/active-rfcs/0000-sfc-script-setup.md
@@ -102,13 +102,13 @@ export default {
 
 ## Declaring props or additional options
 
-One problem with `<script setup>` is that it removes the ability to declare other component options, for example `props`. We can solve this by checking a special export, `$options`:
+One problem with `<script setup>` is that it removes the ability to declare other component options, for example `props`. We can solve this by treating the default export as additional options (this also aligns with normal `<script>`):
 
 ```vue
 <script setup>
 import { computed } from 'vue'
 
-export const $options = {
+export default {
   props: {
     msg: String
   },
@@ -124,15 +124,11 @@ This will compile to:
 ```js
 import { computed } from 'vue'
 
-const $options = {
+export default {
   props: {
     msg: String
   },
-  inheritAttrs: false
-}
-
-export default {
-  ...$options,
+  inheritAttrs: false,
   setup($props) {
     const computedMsg = computed(() => $props.msg + '!!!')
 

From b1c7267cd67440ba1db5f9e477c205a9685397dc Mon Sep 17 00:00:00 2001
From: Evan You <yyx990803@gmail.com>
Date: Fri, 17 Jul 2020 15:05:59 -0400
Subject: [PATCH 08/20] update `<script setup>` details + require setup
 signature via attribute value

---
 active-rfcs/0000-sfc-script-setup.md | 181 ++++++++++++---------------
 1 file changed, 78 insertions(+), 103 deletions(-)

diff --git a/active-rfcs/0000-sfc-script-setup.md b/active-rfcs/0000-sfc-script-setup.md
index 4f68e98f..c6fb46e1 100644
--- a/active-rfcs/0000-sfc-script-setup.md
+++ b/active-rfcs/0000-sfc-script-setup.md
@@ -15,10 +15,10 @@ Introduce a compile step for `<script setup>` to improve the authoring experienc
 </template>
 
 <script setup>
-import { ref } from 'vue'
+  import { ref } from 'vue'
 
-export const count = ref(0)
-export const inc = () => count.value++
+  export const count = ref(0)
+  export const inc = () => count.value++
 </script>
 ```
 
@@ -36,9 +36,9 @@ export default {
 
     return {
       count,
-      inc
+      inc,
     }
-  }
+  },
 }
 ```
 
@@ -70,33 +70,31 @@ When a `<script>` tag in an SFC has the `setup` attribute, it is compiled so tha
 
 ## Using `setup()` arguments
 
-The following equivalent of `setup()` arguments are implicitly available inside `<script setup>`:
-
-- `$props`
-- `$attrs`
-- `$slots`
-- `$emit`
+Setup arguments can be specified as the value of the `setup` attribute:
 
-The example code
-
-```js
+```vue
+<script setup="props, { emit }">
 import { watchEffect } from 'vue'
 
-watchEffect(() => console.log($props.msg))
-$emit('foo')
+watchEffect(() => console.log(props.msg))
+emit('foo')
+</script>
 ```
 
-would be compiled into:
+will be compiled into:
 
 ```js
 import { watchEffect } from 'vue'
 
+// setup is exported as a named export so it can be imported and tested
+export function setup(props, { emit }) {
+  watchEffect(() => console.log(props.msg))
+  emit('foo')
+  return {}
+}
+
 export default {
-  setup($props, { emit: $emit }) {
-    watchEffect(() => console.log($props.msg))
-    $emit('foo')
-    return {}
-  }
+  setup,
 }
 ```
 
@@ -105,17 +103,17 @@ export default {
 One problem with `<script setup>` is that it removes the ability to declare other component options, for example `props`. We can solve this by treating the default export as additional options (this also aligns with normal `<script>`):
 
 ```vue
-<script setup>
+<script setup="props">
 import { computed } from 'vue'
 
 export default {
   props: {
-    msg: String
+    msg: String,
   },
-  inheritAttrs: false
+  inheritAttrs: false,
 }
 
-export const computedMsg = computed(() => $props.msg + '!!!')
+export const computedMsg = computed(() => props.msg + '!!!')
 </script>
 ```
 
@@ -124,21 +122,27 @@ This will compile to:
 ```js
 import { computed } from 'vue'
 
-export default {
+const __default__ = {
   props: {
-    msg: String
+    msg: String,
   },
   inheritAttrs: false,
-  setup($props) {
-    const computedMsg = computed(() => $props.msg + '!!!')
+}
 
-    return {
-      computedMsg
-    }
+export function setup(props) {
+  const computedMsg = computed(() => props.msg + '!!!')
+
+  return {
+    computedMsg,
   }
 }
+
+__default__.setup = setup
+export default __default__
 ```
 
+Since `export default` is hoisted outside of `setup()`, it cannot reference variables declared inside. For example, if the default export object references `computedMsg`, it will result in a compile-time error.
+
 ## With TypeScript
 
 `<script setup>` should just work with TypeScript in most cases. To make implicitly injected variables like `$props` and `$emit` work with proper types, simply declare them:
@@ -166,112 +170,83 @@ import { computed, defineComponent } from 'vue'
 type __$props__ = { msg: string }
 
 export default defineComponent({
-  props: (['msg'] as unknown) as undefined,
+  props: ({
+    msg: String
+  } as unknown) as undefined,
   setup($props: __$props__) {
     const computedMsg = computed(() => $props.msg + '!!!')
 
     return {
-      computedMsg
+      computedMsg,
     }
-  }
+  },
 })
 </script>
 ```
 
-- Runtime props declaration is automatically generated from TS typing to remove the need of double declaration and still ensure correct runtime behavior. (It is force casted into `undefined` to ensure the user provided type is used in the emitted code)
-
-- The emitted code is still TypeScript with valid typing, which can be further processed by other tools.
+- Runtime props declaration is automatically generated from TS typing to remove the need of double declaration and still ensure correct runtime behavior.
 
-# Drawbacks
+  - In dev mode, the compiler will try to infer corresponding runtime validation from the types. For example here `msg: String` is inferred from the `msg: string` type.
 
-This is yet another way of authoring components, and it requires understanding the Composition API first.
+  - In prod mode, the compiler will generate the array format declaration to reduce bundle size (the props here will be compiled into `['msg']`)
 
-# Adoption strategy
+  - The generated props declaration is force casted into `undefined` to ensure the user provided type is used in the emitted code.
 
-This is a fully backwards compatible new feature.
+- The emitted code is still TypeScript with valid typing, which can be further processed by other tools.
 
 
-# Unresolved Questions
+## Usage alongside normal `<script>`
 
-## Magic `let` bindings
+There are some cases where the code must be executed in the module scope, for example:
 
-> Note: This section is not a part of this RFC but included here merely for reference.
+- Declaring named exports that can be imported from the SFC file (`import { named } from './Foo.vue'`)
 
-It is technically possible to compile `let` bindings in a way so that root level `let` bindings are implicitly reactive:
+- Global side effects that should only execute once.
 
-```vue
-<script setup>
-export let count = 0
-
-export function increment() {
-  count++
-}
-</script>
-```
-
-can be compiled into:
+In such cases, a normal `<script>` block can be used alongside `<script setup>`:
 
 ```vue
 <script>
-import { reactive } from 'vue'
+performGlobalSideEffect()
 
-export default {
-  setup() {
-    const __ctx__ = shallowReactive({})
-    __ctx__.count = 0
+// this can be imported as `import { named } from './*.vue'`
+export const named = 1
+</script>
 
-    function increment() {
-      __ctx__.count++
-    }
+<script setup>
+import { ref } from 'vue'
 
-    return Object.assign(__ctx__, {
-      increment
-    })
-  }
-}
+export const count = ref(0)
 </script>
 ```
 
-This makes the code even more succinct and removes the need to use `ref` in the root scope of the component. However, this may be a bit too magical and there are a number of consistency issues if we enable this behavior:
+the above will compile to:
 
-- Objects are not implicitly reactive:
-
-  ```js
-  export const state = { count: 0 }
-
-  export function increment() {
-    // doesn't work
-    state.count++
-  }
-  ```
-
-  Making root scope objects deeply reactive by default can lead to potential performance problems, since the user may declare a 3rd party object of unknown size.
+```js
+import { ref } from 'vue'
 
-- Doesn't work inside nested functions:
+performGlobalSideEffect()
 
-  ```js
-  function useFeature() {
-    // not reactive, since it's not root level
-    let count = 1
-    const inc = () => count++
+export const named = 1
 
-    return {
-      count,
-      inc
-    }
+export function setup() {
+  const count = ref(0)
+  return {
+    count
   }
-  ```
+}
+
+export default { setup }
+```
 
-  If we also compile functions inside `<script setup>`, then composition functions inside and outside SFCs will behave *very* differently and the mental model is no longer consistent. It also creates friction for extracting reusable functions out of components.
+## Usage Restrictions
 
-- Dependency tracking no longer explicit:
+Due to the difference in module execution semantics, code inside `<script setup>` relies on the context of an SFC. When moved into external `.js` or `.ts` files, it may lead to confusions for both developers and tools. Therefore, **`<script setup>`** cannot be used with the `src` attribute.
 
-  ```js
-  export let count = 0
+# Drawbacks
 
-  watchEffect(() => console.log(count))
-  ```
+This is yet another way of authoring components, and it requires understanding the Composition API first.
 
-  By looking at the `watchEffect` callback alone, it is not immediately clear whether it tracks any dependencies at all. We will now need to check if a variable is declared via root level `let` to be sure.
+# Adoption strategy
 
-Given the above considerations, magical `let` bindings is not a part of the proposed features of this RFC, but it's discussed here to provide context on why we chose not to include it.
+This is a fully backwards compatible new feature.

From 3a2b0e7e03febd0bb66745d66593119a6ced23d9 Mon Sep 17 00:00:00 2001
From: Evan You <yyx990803@gmail.com>
Date: Fri, 17 Jul 2020 15:07:38 -0400
Subject: [PATCH 09/20] update `<style vars>` proposal

- use `vars` instead of `:vars`
- default all variables to local in scoped + vars mode
- remove expression syntax restrictions
---
 active-rfcs/0000-sfc-style-variables.md | 48 +++++++++++++++++--------
 1 file changed, 33 insertions(+), 15 deletions(-)

diff --git a/active-rfcs/0000-sfc-style-variables.md b/active-rfcs/0000-sfc-style-variables.md
index 2519ec72..c68bcaa9 100644
--- a/active-rfcs/0000-sfc-style-variables.md
+++ b/active-rfcs/0000-sfc-style-variables.md
@@ -24,7 +24,7 @@ export default {
 }
 </script>
 
-<style :vars="{ color }">
+<style vars="{ color }">
 .text {
   color: var(--color);
 }
@@ -39,9 +39,9 @@ Now with [most modern browsers supporting native CSS variables](https://caniuse.
 
 # Detailed design
 
-The `<style>` tag in an SFC now supports a `:vars` binding, which accepts an expression for the key/values to inject as CSS variables. The expression must be an object literal and cannot contain computed keys (the compiler will warn such cases - see reasoning in the next section). Other than that, it is evaluated in the same context as expressions inside `<template>`.
+The `<style>` tag in an SFC now supports a `vars` binding, which accepts an expression for the key/values to inject as CSS variables. It is evaluated in the same context as expressions inside `<template>`.
 
-The variables will be applied to the component's root element as inline styles. In the above example, given a `:vars` binding that evaluates to `{ color: 'red' }`, the rendered HTML will be:
+The variables will be applied to the component's root element as inline styles. In the above example, given a `vars` binding that evaluates to `{ color: 'red' }`, the rendered HTML will be:
 
 ```html
 <div style="--color:red" class="text">hello</div>
@@ -49,33 +49,51 @@ The variables will be applied to the component's root element as inline styles.
 
 ## Usage with `<style scoped>`
 
-When `:vars` is used with `<style scoped>`, we need to make sure the CSS variables do not leak to descendent components or accidentally shadow CSS variables higher up the DOM tree. The applied CSS variables will be prefixed with the component's scope ID:
+When `vars` is used with `<style scoped>`, we need to make sure the CSS variables do not leak to descendent components or accidentally shadow CSS variables higher up the DOM tree. The applied CSS variables will be prefixed with the component's scope ID:
 
 ```html
-<div style="--v-6b53742-color:red" class="text">hello</div>
+<div style="--6b53742-color:red" class="text">hello</div>
 ```
 
-Similarly, CSS variables inside `<style>` that matches the keys in the `:vars` expression will also be rewritten accordingly. This is also why we require the `:vars` expression to be an object literal with no computed keys.
+Similarly, CSS variables inside `<style>` will also need be rewritten accordingly. With the following code:
 
-# Alternatives
+```html
+<style scoped vars="{ color }">
+h1 {
+  color: var(--color);
+}
+</style>
+```
+
+The inner CSS will be compiled into:
 
-## Auto Detect Variables
+```css
+h1 {
+  color: var(--6b53742-color);
+}
+```
 
-One of the considered alternatives is auto detecting variables to inject using a naming convention:
+**Note that when `scoped` and `vars` are both present, all CSS variables are considered to be local.** In order to reference a global CSS variable here, use the `global:` prefix:
 
 ```html
-<style>
-.text {
-  color: var(--v-color);
+<style scoped vars="{ color }">
+h1 {
+  color: var(--color);
+  font-size: var(--global:fontSize);
 }
 </style>
 ```
 
-However, this has a few disadvantages:
+The above compiles into:
 
-- Intention is less explicit;
+```css
+h1 {
+  color: var(--6b53742-color);
+  font-size: var(--fontSize);
+}
+```
 
-- Requires a full PostCSS parse first to extract matching variables before the main script can be processed. With `:vars` being declared on the `<style>` tag, the compiler can process the `<script>` part without parsing the CSS at all.
+When there is only `scoped` and no `vars`, CSS variables are untouched. This preserves backwards compatibility.
 
 # Adoption strategy
 

From 3e0e5c8eb77d5f406746c0bf787125495eef2654 Mon Sep 17 00:00:00 2001
From: Evan You <yyx990803@gmail.com>
Date: Sat, 18 Jul 2020 16:35:45 -0400
Subject: [PATCH 10/20] update TS section regarding setup argument usage

---
 active-rfcs/0000-sfc-script-setup.md | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/active-rfcs/0000-sfc-script-setup.md b/active-rfcs/0000-sfc-script-setup.md
index c6fb46e1..2d8387f2 100644
--- a/active-rfcs/0000-sfc-script-setup.md
+++ b/active-rfcs/0000-sfc-script-setup.md
@@ -145,19 +145,19 @@ Since `export default` is hoisted outside of `setup()`, it cannot reference vari
 
 ## With TypeScript
 
-`<script setup>` should just work with TypeScript in most cases. To make implicitly injected variables like `$props` and `$emit` work with proper types, simply declare them:
+`<script setup>` should just work with TypeScript in most cases. To type setup arguments like `props` and `emit`,, simply declare them:
 
 ```vue
-<script setup lang="ts">
+<script setup="props" lang="ts">
 import { computed } from 'vue'
 
 // declare props using TypeScript syntax
 // this will be auto compiled into runtime equivalent!
-declare const $props: {
+declare const props: {
   msg: string
 }
 
-export const computedMsg = computed(() => $props.msg + '!!!')
+export const computedMsg = computed(() => props.msg + '!!!')
 </script>
 ```
 
@@ -167,19 +167,19 @@ The above will compile to:
 <script lang="ts">
 import { computed, defineComponent } from 'vue'
 
-type __$props__ = { msg: string }
-
 export default defineComponent({
   props: ({
     msg: String
   } as unknown) as undefined,
-  setup($props: __$props__) {
-    const computedMsg = computed(() => $props.msg + '!!!')
+  setup(props: {
+    msg: string
+  }) {
+    const computedMsg = computed(() => props.msg + '!!!')
 
     return {
       computedMsg,
     }
-  },
+  }
 })
 </script>
 ```

From 45365a9560ef1a1147ee53eccbc8cbb9771f2cbc Mon Sep 17 00:00:00 2001
From: Evan You <yyx990803@gmail.com>
Date: Tue, 25 Aug 2020 17:48:28 -0400
Subject: [PATCH 11/20] edit(sfc): add details on exposing components,
 transform API and binding optimization

---
 active-rfcs/0000-sfc-script-setup.md | 90 ++++++++++++++++++++++++++++
 1 file changed, 90 insertions(+)

diff --git a/active-rfcs/0000-sfc-script-setup.md b/active-rfcs/0000-sfc-script-setup.md
index 2d8387f2..33b6e04c 100644
--- a/active-rfcs/0000-sfc-script-setup.md
+++ b/active-rfcs/0000-sfc-script-setup.md
@@ -98,6 +98,24 @@ export default {
 }
 ```
 
+## Exposing Components
+
+Exports from `<script setup>` are also available to the template when rendering components. For example:
+
+```vue
+<script setup>
+export { default as Foo } from './Foo.vue'
+export { default as Bar } from './Bar.vue'
+export const ok = Math.random()
+</script>
+
+<template>
+  <Foo/>
+  <Bar/>
+  <component :is="ok ? Foo : Bar"/>
+</template>
+```
+
 ## Declaring props or additional options
 
 One problem with `<script setup>` is that it removes the ability to declare other component options, for example `props`. We can solve this by treating the default export as additional options (this also aligns with normal `<script>`):
@@ -194,6 +212,7 @@ export default defineComponent({
 
 - The emitted code is still TypeScript with valid typing, which can be further processed by other tools.
 
+Note that the `props` type declaration value cannot be an imported type, because the SFC compiler does not process external files to extract the prop names.
 
 ## Usage alongside normal `<script>`
 
@@ -239,6 +258,77 @@ export function setup() {
 export default { setup }
 ```
 
+## Transform API
+
+The `@vue/compiler-sfc` package exposes the `compileScript` method for processing `<script setup>`:
+
+```js
+import { parse, compileScript } from '@vue/compiler-sfc'
+
+const descriptor = parse(`...`)
+
+if (descriptor.scriptSetup) {
+  const result = compileScript(descriptor) // returns SFCScriptBlock
+  console.log(result.code)
+  console.log(result.bindings) // see next section
+}
+```
+
+The compilation requires the entire descriptor to be provided, and the resulting code will include sources from both `<script setup>` and normal `<script>` (if present). It is the higher level tools' (e.g. `vite` or `vue-loader`) responsibility to properly assemble the compiled output.
+
+## Template Binding Optimization
+
+The `SFCScriptBlock` returned by `compiledScript` also exposes a `bindings` object, which is the exported binding metadata gathered during the compilation. For example, given the following `<script setup>`:
+
+```vue
+<script setup="props">
+export const foo = 1
+
+export default {
+  props: ['bar']
+}
+</script>
+```
+
+The `bindings` object will be:
+
+```js
+{
+  foo: 'setup',
+  bar: 'props'
+}
+```
+
+This object can then be passed to the template compiler:
+
+```js
+import { compile } from '@vue/compiler-dom'
+
+compile(template, {
+  bindingMetadata: bindings
+})
+```
+
+With the binding metadata available, the template compiler can generate code that directly access template variables from the corresponding source, without having to go through the render context proxy:
+
+```html
+<div>{{ foo + bar }}</div>
+```
+
+```js
+// code generated without bindingMetadata
+// here _ctx is a Proxy object that dynamically dispatches property access
+function render(_ctx) {
+  return createVNode('div', null, _ctx.foo + _ctx.bar)
+}
+
+// code generated with bindingMetadata
+// bypasses the render context proxy
+function render(_ctx, _cache, $setup, $props, $data) {
+  return createVNode('div', null, $setup.foo + $props.bar)
+}
+```
+
 ## Usage Restrictions
 
 Due to the difference in module execution semantics, code inside `<script setup>` relies on the context of an SFC. When moved into external `.js` or `.ts` files, it may lead to confusions for both developers and tools. Therefore, **`<script setup>`** cannot be used with the `src` attribute.

From 6adbdbde0b4e12970001df4eb29f3a1dcab65800 Mon Sep 17 00:00:00 2001
From: Evan You <yyx990803@gmail.com>
Date: Tue, 25 Aug 2020 17:48:40 -0400
Subject: [PATCH 12/20] remove component sugar rfc

---
 active-rfcs/0000-sfc-component-sugar.md | 132 ------------------------
 1 file changed, 132 deletions(-)
 delete mode 100644 active-rfcs/0000-sfc-component-sugar.md

diff --git a/active-rfcs/0000-sfc-component-sugar.md b/active-rfcs/0000-sfc-component-sugar.md
deleted file mode 100644
index 2fe0b737..00000000
--- a/active-rfcs/0000-sfc-component-sugar.md
+++ /dev/null
@@ -1,132 +0,0 @@
-- Start Date: 2020-06-29
-- Target Major Version: 2.x & 3.x
-- Reference Issues: N/A
-- Implementation PR: N/A
-
-# Summary
-
-Syntax sugar for reducing component import and registration boilerplate in Single File Components.
-
-# Basic example
-
-```html
-<component src="./Foo.vue"/>
-<component async src="./Bar.vue"/>
-<component src="./Baz.vue" as="Qux" />
-
-<template>
-  <Foo/>
-  <Bar/>
-  <Qux/>
-</template>
-```
-
-# Motivation
-
-Currently in SFCs you have to import a component and then pass it to the `export default { components: { ... } }` hash, which leads to a lot of redundancy: for a single component we are repeating its name 3 times: in the imported binding, the file name, and the components option.
-
-The `<component/>` sugar requires the name of each component to be specified only once.
-
-# Detailed design
-
-## Normal Components
-
-**Before**
-
-```html
-<template>
-  <Foo/>
-</template>
-
-<script>
-import Foo from './Foo.vue'
-
-export default {
-  components: {
-    Foo
-  }
-}
-</script>
-```
-
-**After**
-
-```html
-<component src="./Foo.vue"/>
-
-<template>
-  <Foo/>
-</template>
-```
-
-## Async Components
-
-**Before**
-
-```html
-<template>
-  <Foo/>
-</template>
-
-<script>
-import { defineAsyncComponent } from 'vue'
-
-export default {
-  components: {
-    Foo: defineAsyncComponent(() => import('./Foo.vue'))
-  }
-}
-</script>
-```
-
-**After**
-
-```html
-<component async src="./Foo.vue" />
-
-<template>
-  <Foo/>
-</template>
-```
-
-## Component Renaming
-
-By default, the component's locally registered name is inferred from its filename. But they can be renamed locally:
-
-```html
-<component src="./Foo.vue" as="Bar" />
-
-<template>
-  <Bar/>
-</template>
-```
-
-# Drawbacks
-
-This would require updates in tools that parse SFC content for template analysis - e.g. Vetur & `@vuedx`.
-
-However, since this information is going to be provided directly by `@vue/compiler-sfc` in the parsed SFC descriptor, it should remove some extra complexity from these tools as well.
-
-# Alternatives
-
-We considered implicitly registering imported components:
-
-```html
-<template>
-  <Foo/>
-</template>
-
-<script>
-import Foo from './Foo.vue'
-</script>
-```
-
-However, this approach has a few issues:
-
-- `Foo` is unused in the script scope, making it annoying when using linter rules that check for unused variables.
-
-- The only safe assumption about an import being a Vue component is the `.vue` extension, which makes it unable to support components authored in non-SFC formats (e.g. `import Foo from './Foo.ts'` can be a component but we can't really be sure).
-
-# Adoption strategy
-
-This is a fully backwards compatible new feature. However, we probably want to warn users against mixing the manual imports and `<component>` tags so that tools that rely on the extracted information can make safer assumptions.

From c0de1700442af8e917893a798000685e32738274 Mon Sep 17 00:00:00 2001
From: Evan You <yyx990803@gmail.com>
Date: Thu, 27 Aug 2020 09:14:49 -0400
Subject: [PATCH 13/20] update transform API example

---
 active-rfcs/0000-sfc-script-setup.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/active-rfcs/0000-sfc-script-setup.md b/active-rfcs/0000-sfc-script-setup.md
index 33b6e04c..f0ad3070 100644
--- a/active-rfcs/0000-sfc-script-setup.md
+++ b/active-rfcs/0000-sfc-script-setup.md
@@ -267,7 +267,7 @@ import { parse, compileScript } from '@vue/compiler-sfc'
 
 const descriptor = parse(`...`)
 
-if (descriptor.scriptSetup) {
+if (descriptor.script || descriptor.scriptSetup) {
   const result = compileScript(descriptor) // returns SFCScriptBlock
   console.log(result.code)
   console.log(result.bindings) // see next section

From e19fcb924bcdf42a6b930cdacd5d3b72100c946c Mon Sep 17 00:00:00 2001
From: Weiqi Wu <295290708@qq.com>
Date: Wed, 2 Sep 2020 15:26:28 +0800
Subject: [PATCH 14/20] typo (#207)

---
 active-rfcs/0000-sfc-script-setup.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/active-rfcs/0000-sfc-script-setup.md b/active-rfcs/0000-sfc-script-setup.md
index f0ad3070..e42e85bb 100644
--- a/active-rfcs/0000-sfc-script-setup.md
+++ b/active-rfcs/0000-sfc-script-setup.md
@@ -163,7 +163,7 @@ Since `export default` is hoisted outside of `setup()`, it cannot reference vari
 
 ## With TypeScript
 
-`<script setup>` should just work with TypeScript in most cases. To type setup arguments like `props` and `emit`,, simply declare them:
+`<script setup>` should just work with TypeScript in most cases. To type setup arguments like `props` and `emit`, simply declare them:
 
 ```vue
 <script setup="props" lang="ts">

From 481bd16844e6d8172a7241e47d31de5671074d2f Mon Sep 17 00:00:00 2001
From: Evan You <yyx990803@gmail.com>
Date: Mon, 31 Aug 2020 10:44:04 -0400
Subject: [PATCH 15/20] add reactive let bindings to `<script setup>` RFC

---
 active-rfcs/0000-sfc-script-setup.md | 129 +++++++++++++++++++++++++--
 1 file changed, 123 insertions(+), 6 deletions(-)

diff --git a/active-rfcs/0000-sfc-script-setup.md b/active-rfcs/0000-sfc-script-setup.md
index e42e85bb..bc93baee 100644
--- a/active-rfcs/0000-sfc-script-setup.md
+++ b/active-rfcs/0000-sfc-script-setup.md
@@ -47,15 +47,15 @@ In addition, one of the most often complained about aspect of the Composition AP
 This RFC introduces a compiler-powered alternative for the usage of `<script>` inside SFCs that greatly reduces the amount of boilerplate:
 
 ```diff
-import { ref } from 'vue'
-
+- import { ref } from 'vue'
+-
 -export default {
 -  setup() {
 -    const count = ref(0)
-+export const count = ref(0)
++export let count = 0
 -    const inc = () => count.value++
-+export const inc = () => count.value++
-
++export const inc = () => count++
+-
 -    return {
 -      count,
 -      inc
@@ -68,6 +68,115 @@ import { ref } from 'vue'
 
 When a `<script>` tag in an SFC has the `setup` attribute, it is compiled so that the code runs in the context of the `setup()` function of the component. All ES module exports are considered values to be exposed to the render context and included in the `setup()` return object.
 
+## Reactive `let` bindings
+
+Root scope `let` bindings are implicitly compiled into refs:
+
+```vue
+<script setup>
+export let count = 0
+
+export function increment() {
+  count++
+}
+</script>
+```
+
+is compiled into:
+
+```vue
+<script setup>
+import { ref } from 'vue'
+
+export default {
+  setup() {
+    let count = ref(0)
+
+    function increment() {
+      count.value++
+    }
+
+    return {
+      count
+    }
+  }
+}
+</script>
+```
+
+Details:
+
+1. This only affects **root level `let` bindings**. `const` declarations and variables declared inside nested functions are not affected:
+
+    ```vue
+    <script setup>
+    // reactive, compiled to ref
+    export let count = 0
+    // not reactive
+    export const max = 10
+    </script>
+    ```
+
+2. Objects declared using root level `let` are deeply reactive (because we are using `ref`):
+
+    ```vue
+    <script setup>
+    // converted with deep reactivity
+    export let state = {
+      count: 0
+    }
+
+    export function increment() {
+      // mutation works
+      state.count++
+      // replacement also works
+      state = { count: 2 }
+    }
+
+    // untouched - mutations are not reactive.
+    // if `config` expects to trigger reactive updates, use `let` instead.
+    export const config = {
+      foo: true
+    }
+    // will not trigger change
+    config.foo = false
+    </script>
+    ```
+
+    **Rule of thumb: use `let` for reactive values, use `const` for non-reactive values.**
+
+3. References to a root level `let` binding are compiled to automatically access its `.value`, so reactivity works whenever they are referenced:
+
+    ```vue
+    <script setup>
+    import { computed, watchEffect } from 'vue'
+
+    let count = 0
+
+    export const double = computed(() => count * 2)
+
+    watchEffect(() => {
+      console.log(`count is: ${count}`)
+    })
+    </script>
+    ```
+
+    Note that `watch` on a let binding does not work, because it is equivalent to `watch(ref.value)`. You will have to wrap it in a getter:
+
+    ```vue
+    <script setup>
+    import { watch } from 'vue'
+
+    let count = 0
+
+    watch(() => count, newCount => {
+      console.log(`count changed: ${newCount}`)
+    })
+    </script>
+    ```
+
+4. You can still use the Composition API to explicitly create refs (e.g. shallow or custom refs) or reactive objects. In fact, the entire reactive let binding feature is just additive syntax sugar - you can use `<script setup>` without relying on it. The API also provides an option to disable it altogether.
+
 ## Using `setup()` arguments
 
 Setup arguments can be specified as the value of the `setup` attribute:
@@ -268,7 +377,15 @@ import { parse, compileScript } from '@vue/compiler-sfc'
 const descriptor = parse(`...`)
 
 if (descriptor.script || descriptor.scriptSetup) {
-  const result = compileScript(descriptor) // returns SFCScriptBlock
+  // All options are optional.
+  const options = {
+    // https://babeljs.io/docs/en/babel-parser#plugins
+    babelParserPlugins: []
+    // enable/disable reactive let? (default: true)
+    reactiveLet: false
+  }
+
+  const result = compileScript(descriptor, options) // returns SFCScriptBlock
   console.log(result.code)
   console.log(result.bindings) // see next section
 }

From 2666310894617729a4031ccf6ed78c4d6b894db2 Mon Sep 17 00:00:00 2001
From: Evan You <yyx990803@gmail.com>
Date: Mon, 9 Nov 2020 11:33:40 -0500
Subject: [PATCH 16/20] remove script setup

---
 active-rfcs/0000-sfc-script-setup.md | 459 ---------------------------
 1 file changed, 459 deletions(-)
 delete mode 100644 active-rfcs/0000-sfc-script-setup.md

diff --git a/active-rfcs/0000-sfc-script-setup.md b/active-rfcs/0000-sfc-script-setup.md
deleted file mode 100644
index bc93baee..00000000
--- a/active-rfcs/0000-sfc-script-setup.md
+++ /dev/null
@@ -1,459 +0,0 @@
-- Start Date: 2020-06-29
-- Target Major Version: 2.x & 3.x
-- Reference Issues: N/A
-- Implementation PR: N/A
-
-# Summary
-
-Introduce a compile step for `<script setup>` to improve the authoring experience when using the Composition API inside Single File Components.
-
-# Basic example
-
-```html
-<template>
-  <button @click="inc">{{ count }}</button>
-</template>
-
-<script setup>
-  import { ref } from 'vue'
-
-  export const count = ref(0)
-  export const inc = () => count.value++
-</script>
-```
-
-# Motivation
-
-When authoring components using the Composition API, very often `setup` is the only option that's being used. This results in some unnecessary boilerplate:
-
-```js
-import { ref } from 'vue'
-
-export default {
-  setup() {
-    const count = ref(0)
-    const inc = () => count.value++
-
-    return {
-      count,
-      inc,
-    }
-  },
-}
-```
-
-In addition, one of the most often complained about aspect of the Composition API is the necessity to repeat all the bindings that need to be exposed to the render context using a return object.
-
-This RFC introduces a compiler-powered alternative for the usage of `<script>` inside SFCs that greatly reduces the amount of boilerplate:
-
-```diff
-- import { ref } from 'vue'
--
--export default {
--  setup() {
--    const count = ref(0)
-+export let count = 0
--    const inc = () => count.value++
-+export const inc = () => count++
--
--    return {
--      count,
--      inc
--    }
--  }
--}
-```
-
-# Detailed design
-
-When a `<script>` tag in an SFC has the `setup` attribute, it is compiled so that the code runs in the context of the `setup()` function of the component. All ES module exports are considered values to be exposed to the render context and included in the `setup()` return object.
-
-## Reactive `let` bindings
-
-Root scope `let` bindings are implicitly compiled into refs:
-
-```vue
-<script setup>
-export let count = 0
-
-export function increment() {
-  count++
-}
-</script>
-```
-
-is compiled into:
-
-```vue
-<script setup>
-import { ref } from 'vue'
-
-export default {
-  setup() {
-    let count = ref(0)
-
-    function increment() {
-      count.value++
-    }
-
-    return {
-      count
-    }
-  }
-}
-</script>
-```
-
-Details:
-
-1. This only affects **root level `let` bindings**. `const` declarations and variables declared inside nested functions are not affected:
-
-    ```vue
-    <script setup>
-    // reactive, compiled to ref
-    export let count = 0
-    // not reactive
-    export const max = 10
-    </script>
-    ```
-
-2. Objects declared using root level `let` are deeply reactive (because we are using `ref`):
-
-    ```vue
-    <script setup>
-    // converted with deep reactivity
-    export let state = {
-      count: 0
-    }
-
-    export function increment() {
-      // mutation works
-      state.count++
-      // replacement also works
-      state = { count: 2 }
-    }
-
-    // untouched - mutations are not reactive.
-    // if `config` expects to trigger reactive updates, use `let` instead.
-    export const config = {
-      foo: true
-    }
-    // will not trigger change
-    config.foo = false
-    </script>
-    ```
-
-    **Rule of thumb: use `let` for reactive values, use `const` for non-reactive values.**
-
-3. References to a root level `let` binding are compiled to automatically access its `.value`, so reactivity works whenever they are referenced:
-
-    ```vue
-    <script setup>
-    import { computed, watchEffect } from 'vue'
-
-    let count = 0
-
-    export const double = computed(() => count * 2)
-
-    watchEffect(() => {
-      console.log(`count is: ${count}`)
-    })
-    </script>
-    ```
-
-    Note that `watch` on a let binding does not work, because it is equivalent to `watch(ref.value)`. You will have to wrap it in a getter:
-
-    ```vue
-    <script setup>
-    import { watch } from 'vue'
-
-    let count = 0
-
-    watch(() => count, newCount => {
-      console.log(`count changed: ${newCount}`)
-    })
-    </script>
-    ```
-
-4. You can still use the Composition API to explicitly create refs (e.g. shallow or custom refs) or reactive objects. In fact, the entire reactive let binding feature is just additive syntax sugar - you can use `<script setup>` without relying on it. The API also provides an option to disable it altogether.
-
-## Using `setup()` arguments
-
-Setup arguments can be specified as the value of the `setup` attribute:
-
-```vue
-<script setup="props, { emit }">
-import { watchEffect } from 'vue'
-
-watchEffect(() => console.log(props.msg))
-emit('foo')
-</script>
-```
-
-will be compiled into:
-
-```js
-import { watchEffect } from 'vue'
-
-// setup is exported as a named export so it can be imported and tested
-export function setup(props, { emit }) {
-  watchEffect(() => console.log(props.msg))
-  emit('foo')
-  return {}
-}
-
-export default {
-  setup,
-}
-```
-
-## Exposing Components
-
-Exports from `<script setup>` are also available to the template when rendering components. For example:
-
-```vue
-<script setup>
-export { default as Foo } from './Foo.vue'
-export { default as Bar } from './Bar.vue'
-export const ok = Math.random()
-</script>
-
-<template>
-  <Foo/>
-  <Bar/>
-  <component :is="ok ? Foo : Bar"/>
-</template>
-```
-
-## Declaring props or additional options
-
-One problem with `<script setup>` is that it removes the ability to declare other component options, for example `props`. We can solve this by treating the default export as additional options (this also aligns with normal `<script>`):
-
-```vue
-<script setup="props">
-import { computed } from 'vue'
-
-export default {
-  props: {
-    msg: String,
-  },
-  inheritAttrs: false,
-}
-
-export const computedMsg = computed(() => props.msg + '!!!')
-</script>
-```
-
-This will compile to:
-
-```js
-import { computed } from 'vue'
-
-const __default__ = {
-  props: {
-    msg: String,
-  },
-  inheritAttrs: false,
-}
-
-export function setup(props) {
-  const computedMsg = computed(() => props.msg + '!!!')
-
-  return {
-    computedMsg,
-  }
-}
-
-__default__.setup = setup
-export default __default__
-```
-
-Since `export default` is hoisted outside of `setup()`, it cannot reference variables declared inside. For example, if the default export object references `computedMsg`, it will result in a compile-time error.
-
-## With TypeScript
-
-`<script setup>` should just work with TypeScript in most cases. To type setup arguments like `props` and `emit`, simply declare them:
-
-```vue
-<script setup="props" lang="ts">
-import { computed } from 'vue'
-
-// declare props using TypeScript syntax
-// this will be auto compiled into runtime equivalent!
-declare const props: {
-  msg: string
-}
-
-export const computedMsg = computed(() => props.msg + '!!!')
-</script>
-```
-
-The above will compile to:
-
-```vue
-<script lang="ts">
-import { computed, defineComponent } from 'vue'
-
-export default defineComponent({
-  props: ({
-    msg: String
-  } as unknown) as undefined,
-  setup(props: {
-    msg: string
-  }) {
-    const computedMsg = computed(() => props.msg + '!!!')
-
-    return {
-      computedMsg,
-    }
-  }
-})
-</script>
-```
-
-- Runtime props declaration is automatically generated from TS typing to remove the need of double declaration and still ensure correct runtime behavior.
-
-  - In dev mode, the compiler will try to infer corresponding runtime validation from the types. For example here `msg: String` is inferred from the `msg: string` type.
-
-  - In prod mode, the compiler will generate the array format declaration to reduce bundle size (the props here will be compiled into `['msg']`)
-
-  - The generated props declaration is force casted into `undefined` to ensure the user provided type is used in the emitted code.
-
-- The emitted code is still TypeScript with valid typing, which can be further processed by other tools.
-
-Note that the `props` type declaration value cannot be an imported type, because the SFC compiler does not process external files to extract the prop names.
-
-## Usage alongside normal `<script>`
-
-There are some cases where the code must be executed in the module scope, for example:
-
-- Declaring named exports that can be imported from the SFC file (`import { named } from './Foo.vue'`)
-
-- Global side effects that should only execute once.
-
-In such cases, a normal `<script>` block can be used alongside `<script setup>`:
-
-```vue
-<script>
-performGlobalSideEffect()
-
-// this can be imported as `import { named } from './*.vue'`
-export const named = 1
-</script>
-
-<script setup>
-import { ref } from 'vue'
-
-export const count = ref(0)
-</script>
-```
-
-the above will compile to:
-
-```js
-import { ref } from 'vue'
-
-performGlobalSideEffect()
-
-export const named = 1
-
-export function setup() {
-  const count = ref(0)
-  return {
-    count
-  }
-}
-
-export default { setup }
-```
-
-## Transform API
-
-The `@vue/compiler-sfc` package exposes the `compileScript` method for processing `<script setup>`:
-
-```js
-import { parse, compileScript } from '@vue/compiler-sfc'
-
-const descriptor = parse(`...`)
-
-if (descriptor.script || descriptor.scriptSetup) {
-  // All options are optional.
-  const options = {
-    // https://babeljs.io/docs/en/babel-parser#plugins
-    babelParserPlugins: []
-    // enable/disable reactive let? (default: true)
-    reactiveLet: false
-  }
-
-  const result = compileScript(descriptor, options) // returns SFCScriptBlock
-  console.log(result.code)
-  console.log(result.bindings) // see next section
-}
-```
-
-The compilation requires the entire descriptor to be provided, and the resulting code will include sources from both `<script setup>` and normal `<script>` (if present). It is the higher level tools' (e.g. `vite` or `vue-loader`) responsibility to properly assemble the compiled output.
-
-## Template Binding Optimization
-
-The `SFCScriptBlock` returned by `compiledScript` also exposes a `bindings` object, which is the exported binding metadata gathered during the compilation. For example, given the following `<script setup>`:
-
-```vue
-<script setup="props">
-export const foo = 1
-
-export default {
-  props: ['bar']
-}
-</script>
-```
-
-The `bindings` object will be:
-
-```js
-{
-  foo: 'setup',
-  bar: 'props'
-}
-```
-
-This object can then be passed to the template compiler:
-
-```js
-import { compile } from '@vue/compiler-dom'
-
-compile(template, {
-  bindingMetadata: bindings
-})
-```
-
-With the binding metadata available, the template compiler can generate code that directly access template variables from the corresponding source, without having to go through the render context proxy:
-
-```html
-<div>{{ foo + bar }}</div>
-```
-
-```js
-// code generated without bindingMetadata
-// here _ctx is a Proxy object that dynamically dispatches property access
-function render(_ctx) {
-  return createVNode('div', null, _ctx.foo + _ctx.bar)
-}
-
-// code generated with bindingMetadata
-// bypasses the render context proxy
-function render(_ctx, _cache, $setup, $props, $data) {
-  return createVNode('div', null, $setup.foo + $props.bar)
-}
-```
-
-## Usage Restrictions
-
-Due to the difference in module execution semantics, code inside `<script setup>` relies on the context of an SFC. When moved into external `.js` or `.ts` files, it may lead to confusions for both developers and tools. Therefore, **`<script setup>`** cannot be used with the `src` attribute.
-
-# Drawbacks
-
-This is yet another way of authoring components, and it requires understanding the Composition API first.
-
-# Adoption strategy
-
-This is a fully backwards compatible new feature.

From 3e77b4a35a20c9da17350e759045d6a890d66659 Mon Sep 17 00:00:00 2001
From: Evan You <yyx990803@gmail.com>
Date: Mon, 16 Nov 2020 13:05:02 -0500
Subject: [PATCH 17/20] rework style var proposal

---
 active-rfcs/0000-sfc-style-variables.md | 134 ++++++++++++++++--------
 1 file changed, 91 insertions(+), 43 deletions(-)

diff --git a/active-rfcs/0000-sfc-style-variables.md b/active-rfcs/0000-sfc-style-variables.md
index c68bcaa9..ea040d72 100644
--- a/active-rfcs/0000-sfc-style-variables.md
+++ b/active-rfcs/0000-sfc-style-variables.md
@@ -5,7 +5,7 @@
 
 # Summary
 
-Support injecting component-state-driven CSS variables into Single File Components styles.
+Support using component-state-driven CSS variables into Single File Components styles.
 
 # Basic example
 
@@ -15,19 +15,25 @@ Support injecting component-state-driven CSS variables into Single File Componen
 </template>
 
 <script>
-export default {
-  data() {
-    return {
-      color: 'red'
-    }
+  export default {
+    data() {
+      return {
+        color: 'red',
+        font: {
+          size: '2em'
+        }
+      }
+    },
   }
-}
 </script>
 
-<style vars="{ color }">
-.text {
-  color: var(--color);
-}
+<style>
+  .text {
+    color: var(--v-bind:color);
+
+    /* shorthand + nested property access */
+    font-size: var(--:font.size);
+  }
 </style>
 ```
 
@@ -39,61 +45,103 @@ Now with [most modern browsers supporting native CSS variables](https://caniuse.
 
 # Detailed design
 
-The `<style>` tag in an SFC now supports a `vars` binding, which accepts an expression for the key/values to inject as CSS variables. It is evaluated in the same context as expressions inside `<template>`.
-
-The variables will be applied to the component's root element as inline styles. In the above example, given a `vars` binding that evaluates to `{ color: 'red' }`, the rendered HTML will be:
+The `<style>` tag in an SFC now supports CSS variables that start with the `v-bind:` prefix (or `:` as shorthand), for example:
 
 ```html
-<div style="--color:red" class="text">hello</div>
+<style>
+  .text {
+    color: var(--v-bind:color);
+    font-size: var(--:font.size);
+  }
+</style>
 ```
 
-## Usage with `<style scoped>`
+It should be noted that CSS variables names technically must be valid CSS identifiers which cannot contain characters like `:` or `.`. However, the syntax proposed in this RFC is used purely as a compile-time hint and is **not** included in the final runtime CSS. In terms of tooling integration, all major CSS parsers in the ecosystem can parse `var()` correctly with arbitrary inner content (verified on [ASTExplorer](https://astexplorer.net/)).
 
-When `vars` is used with `<style scoped>`, we need to make sure the CSS variables do not leak to descendent components or accidentally shadow CSS variables higher up the DOM tree. The applied CSS variables will be prefixed with the component's scope ID:
+When such CSS variables are detected, the SFC compiler will perform the following:
 
-```html
-<div style="--6b53742-color:red" class="text">hello</div>
-```
+1. Rewrite the variable to a hashed version. The above will be rewritten to:
 
-Similarly, CSS variables inside `<style>` will also need be rewritten accordingly. With the following code:
+   ```html
+   <style>
+     .text {
+       color: var(--6b53742-color);
+       font-size: var(--6b53742-font_size);
+     }
+   </style>
+   ```
 
-```html
-<style scoped vars="{ color }">
-h1 {
-  color: var(--color);
+   Note the hashing will be applied in all cases, regardless of whether `<style>` tag is scoped or not. This means injected CSS variables will never accidentally leak into child components.
+
+2. The corresponding variables will be injected to the component's root element as inline styles. For the example above, the final rendered DOM will look like this:
+
+   ```html
+   <div style="--6b53742-color:red;--6b53742-font_size:2em" class="text">
+     hello
+   </div>
+   ```
+
+   The injection is reactive - so if the component's `color` property changes, the injected CSS variable will be updated accordingly. This update is applied independent of the component's template update so changes to a CSS-only reactive property won't trigger template re-renders.
+
+## Compilation Details
+
+In order to inject the CSS variables, the compiler needs to generate and inject code like the following into the component's `setup()` function:
+
+```js
+import { useCssVars } from 'vue'
+
+export default {
+  setup() {
+    // ...
+    useCssVars(_ctx => ({
+      color: _ctx.color,
+      font_size: _ctx.font.size
+    }))
+  }
 }
-</style>
 ```
 
-The inner CSS will be compiled into:
+...where the `useCssVars` runtime helper sets up a `watchEffect` to reactively apply the variables to the DOM.
+
+# Drawbacks
+
+## Compilation cost
+
+The compilation strategy requires the script compilation to do a parse of the `<style>` tag content first in order to determine the list of variables to expose. This will result in some duplicated CSS parsing cost, and will also cause `<style>` changes that affect the injected variables list to trigger HMR updates that reset the component state because it alters the generated JavaScript.
+
+## Prettier integration
+
+Currently, Prettier will attempt to format content inside `var(...)` when it contains colons or quotes, even thought technically it should not:
 
 ```css
-h1 {
-  color: var(--6b53742-color);
+.text {
+  color: var(--v-bind:color);
+  font-size: var(--:font.size);
 }
-```
-
-**Note that when `scoped` and `vars` are both present, all CSS variables are considered to be local.** In order to reference a global CSS variable here, use the `global:` prefix:
 
-```html
-<style scoped vars="{ color }">
-h1 {
-  color: var(--color);
-  font-size: var(--global:fontSize);
+/* Prettier will format the above to: */
+.text {
+  color: var(--v-bind: color);
+  font-size: var(--: font.size);
 }
-</style>
 ```
 
-The above compiles into:
+Technically, the compilation strategy can handle this just fine by trimming the bound expression, but it can be a bit of an annoyance to users.
+
+TODO: file prettier issue
+
+# Alternatives
+
+A possible alternative syntax is
 
 ```css
-h1 {
-  color: var(--6b53742-color);
-  font-size: var(--fontSize);
+.text {
+  color: var(--{{ color }});
+  font-size: var(--{{ font.size }});
 }
 ```
 
-When there is only `scoped` and no `vars`, CSS variables are untouched. This preserves backwards compatibility.
+However, [cssom](https://www.npmjs.com/package/cssom), one of the widely used CSS parsers, will strip away the curly braces inside `var()`. This may not be a real issue since `cssom` is primarily used in `jsdom` and not in IDE tooling.
 
 # Adoption strategy
 

From ddeb68f8ea8792f8541d5c0f562a9f3e7a7d00bc Mon Sep 17 00:00:00 2001
From: Evan You <yyx990803@gmail.com>
Date: Mon, 16 Nov 2020 13:43:47 -0500
Subject: [PATCH 18/20] edits

---
 active-rfcs/0000-sfc-style-variables.md | 17 +++--------------
 1 file changed, 3 insertions(+), 14 deletions(-)

diff --git a/active-rfcs/0000-sfc-style-variables.md b/active-rfcs/0000-sfc-style-variables.md
index ea040d72..523dd89d 100644
--- a/active-rfcs/0000-sfc-style-variables.md
+++ b/active-rfcs/0000-sfc-style-variables.md
@@ -107,7 +107,9 @@ export default {
 
 ## Compilation cost
 
-The compilation strategy requires the script compilation to do a parse of the `<style>` tag content first in order to determine the list of variables to expose. This will result in some duplicated CSS parsing cost, and will also cause `<style>` changes that affect the injected variables list to trigger HMR updates that reset the component state because it alters the generated JavaScript.
+The compilation strategy requires the script compilation to do a parse of the `<style>` tag content first in order to determine the list of variables to expose. This will result in some duplicated CSS parsing cost.
+
+In cases where no `v-bind:` variables are used, a quick regex check can skip a full parse, so the feature should have negligible impact on components that are not using it.
 
 ## Prettier integration
 
@@ -130,19 +132,6 @@ Technically, the compilation strategy can handle this just fine by trimming the
 
 TODO: file prettier issue
 
-# Alternatives
-
-A possible alternative syntax is
-
-```css
-.text {
-  color: var(--{{ color }});
-  font-size: var(--{{ font.size }});
-}
-```
-
-However, [cssom](https://www.npmjs.com/package/cssom), one of the widely used CSS parsers, will strip away the curly braces inside `var()`. This may not be a real issue since `cssom` is primarily used in `jsdom` and not in IDE tooling.
-
 # Adoption strategy
 
 This is a fully backwards compatible new feature. However, we should make it clear that it relies on native CSS variables so the user needs to be aware of the browser support range.

From 7be2b1ba8cd8b95fc94e26b2c0a59ed0b5f3bf64 Mon Sep 17 00:00:00 2001
From: Evan You <yyx990803@gmail.com>
Date: Tue, 17 Nov 2020 10:10:45 -0500
Subject: [PATCH 19/20] revise to use v-bind function

---
 active-rfcs/0000-sfc-style-variables.md | 102 +++++++++++-------------
 1 file changed, 46 insertions(+), 56 deletions(-)

diff --git a/active-rfcs/0000-sfc-style-variables.md b/active-rfcs/0000-sfc-style-variables.md
index 523dd89d..b23a2308 100644
--- a/active-rfcs/0000-sfc-style-variables.md
+++ b/active-rfcs/0000-sfc-style-variables.md
@@ -20,8 +20,8 @@ Support using component-state-driven CSS variables into Single File Components s
       return {
         color: 'red',
         font: {
-          size: '2em'
-        }
+          size: '2em',
+        },
       }
     },
   }
@@ -29,10 +29,10 @@ Support using component-state-driven CSS variables into Single File Components s
 
 <style>
   .text {
-    color: var(--v-bind:color);
+    color: v-bind(color);
 
-    /* shorthand + nested property access */
-    font-size: var(--:font.size);
+    /* expressions (wrap in quotes) */
+    font-size: v-bind('font.size');
   }
 </style>
 ```
@@ -45,30 +45,36 @@ Now with [most modern browsers supporting native CSS variables](https://caniuse.
 
 # Detailed design
 
-The `<style>` tag in an SFC now supports CSS variables that start with the `v-bind:` prefix (or `:` as shorthand), for example:
+The `<style>` tag in an SFC now supports a custom CSS function named `v-bind`:
 
 ```html
+<!-- in Vue SFC -->
 <style>
   .text {
-    color: var(--v-bind:color);
-    font-size: var(--:font.size);
+    color: v-bind(color);
   }
 </style>
 ```
 
-It should be noted that CSS variables names technically must be valid CSS identifiers which cannot contain characters like `:` or `.`. However, the syntax proposed in this RFC is used purely as a compile-time hint and is **not** included in the final runtime CSS. In terms of tooling integration, all major CSS parsers in the ecosystem can parse `var()` correctly with arbitrary inner content (verified on [ASTExplorer](https://astexplorer.net/)).
+As expected, this would bind the `color` declaration's value to the `color` property of the component's state, reactively.
+
+The `v-bind` function can support arbitrary JavaScript expressions inside, but since JavaScript expressions may contain characters that are not valid in CSS identifiers, they will need to be wrapped in quotes most of the time:
+
+```css
+.text {
+  font-size: v-bind('theme.font.size');
+}
+```
 
 When such CSS variables are detected, the SFC compiler will perform the following:
 
-1. Rewrite the variable to a hashed version. The above will be rewritten to:
+1. Rewrite the `v-bind()` to a native `var()` with a hashed variable name. The above will be rewritten to:
 
-   ```html
-   <style>
-     .text {
-       color: var(--6b53742-color);
-       font-size: var(--6b53742-font_size);
-     }
-   </style>
+   ```css
+    .text {
+      color: var(--6b53742-color);
+      font-size: var(--6b53742-theme_font_size);
+    }
    ```
 
    Note the hashing will be applied in all cases, regardless of whether `<style>` tag is scoped or not. This means injected CSS variables will never accidentally leak into child components.
@@ -76,7 +82,7 @@ When such CSS variables are detected, the SFC compiler will perform the followin
 2. The corresponding variables will be injected to the component's root element as inline styles. For the example above, the final rendered DOM will look like this:
 
    ```html
-   <div style="--6b53742-color:red;--6b53742-font_size:2em" class="text">
+   <div style="--6b53742-color:red;--6b53742-theme_font_size:2em;" class="text">
      hello
    </div>
    ```
@@ -85,52 +91,36 @@ When such CSS variables are detected, the SFC compiler will perform the followin
 
 ## Compilation Details
 
-In order to inject the CSS variables, the compiler needs to generate and inject code like the following into the component's `setup()` function:
+- In order to inject the CSS variables, the compiler needs to generate and inject code like the following into the component's `setup()` function:
 
-```js
-import { useCssVars } from 'vue'
+  ```js
+  import { useCssVars } from 'vue'
 
-export default {
-  setup() {
-    // ...
-    useCssVars(_ctx => ({
-      color: _ctx.color,
-      font_size: _ctx.font.size
-    }))
+  export default {
+    setup() {
+      // ...
+      useCssVars((_ctx) => ({
+        color: _ctx.color,
+        theme_font_size: _ctx.theme.font.size,
+      }))
+    },
   }
-}
-```
-
-...where the `useCssVars` runtime helper sets up a `watchEffect` to reactively apply the variables to the DOM.
+  ```
 
-# Drawbacks
+  ...where the `useCssVars` runtime helper sets up a `watchEffect` to reactively apply the variables to the DOM.
 
-## Compilation cost
+- The compilation strategy requires the script compilation to do a simple regex parse of the `<style>` tag content first in order to determine the list of variables to expose. However, this parse phase won't be as costly as a full AST-based parse.
 
-The compilation strategy requires the script compilation to do a parse of the `<style>` tag content first in order to determine the list of variables to expose. This will result in some duplicated CSS parsing cost.
+- In production, the variable names can be further hashed to reduce CSS footprint:
 
-In cases where no `v-bind:` variables are used, a quick regex check can skip a full parse, so the feature should have negligible impact on components that are not using it.
-
-## Prettier integration
-
-Currently, Prettier will attempt to format content inside `var(...)` when it contains colons or quotes, even thought technically it should not:
-
-```css
-.text {
-  color: var(--v-bind:color);
-  font-size: var(--:font.size);
-}
-
-/* Prettier will format the above to: */
-.text {
-  color: var(--v-bind: color);
-  font-size: var(--: font.size);
-}
-```
-
-Technically, the compilation strategy can handle this just fine by trimming the bound expression, but it can be a bit of an annoyance to users.
+   ```css
+    .text {
+      color: var(--x3b2fs2);
+      font-size: var(--29fh29g);
+    }
+   ```
 
-TODO: file prettier issue
+   Corresponding generated JavaScript code will be using the same hashes accordingly.
 
 # Adoption strategy
 

From 0d247544113f415a45645d34347c9826a036af67 Mon Sep 17 00:00:00 2001
From: Evan You <yyx990803@gmail.com>
Date: Fri, 16 Jul 2021 14:57:07 -0400
Subject: [PATCH 20/20] adjust RFC number

---
 .../{0000-sfc-style-variables.md => 0043-sfc-style-variables.md}  | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename active-rfcs/{0000-sfc-style-variables.md => 0043-sfc-style-variables.md} (100%)

diff --git a/active-rfcs/0000-sfc-style-variables.md b/active-rfcs/0043-sfc-style-variables.md
similarity index 100%
rename from active-rfcs/0000-sfc-style-variables.md
rename to active-rfcs/0043-sfc-style-variables.md