From 3babae58bbc7fa074ab0ff854c87029f41593f9c Mon Sep 17 00:00:00 2001
From: Evan You <yyx990803@gmail.com>
Date: Fri, 30 Oct 2020 17:17:25 -0400
Subject: [PATCH 01/20] new script setup and ref sugar

---
 active-rfcs/0000-script-setup.md | 821 +++++++++++++++++++++++++++++++
 1 file changed, 821 insertions(+)
 create mode 100644 active-rfcs/0000-script-setup.md

diff --git a/active-rfcs/0000-script-setup.md b/active-rfcs/0000-script-setup.md
new file mode 100644
index 00000000..48611985
--- /dev/null
+++ b/active-rfcs/0000-script-setup.md
@@ -0,0 +1,821 @@
+- Start Date: 2020-10-28
+- Target Major Version: 3.x
+- Reference Issues: https://github.com/vuejs/rfcs/pull/182
+- Implementation PR: https://github.com/vuejs/vue-next/pull/2532
+
+# Summary
+
+- Introduce a new script type in Single File Components: `<script setup>`, which exposes all its top level bindings to the template.
+
+- Introduce a compiler-based syntax sugar for using refs without `.value` inside `<script setup>`.
+
+- **Note:** this is intended to replace the current `<script setup>` as proposed in [#182](https://github.com/vuejs/rfcs/pull/182).
+
+# Basic example
+
+```html
+<script setup>
+// imported components are directly usable in template
+import Foo from './Foo.vue'
+
+// declaring a variable that compiles to a ref
+ref: count = 1
+
+function inc() {
+  // the variable can be used like a plain value
+  count++
+}
+
+// access the raw ref object by prefixing with $
+console.log($count.value)
+</script>
+
+<template>
+  <Foo :count="count" @click="inc" />
+</template>
+```
+
+<details>
+<summary>Compiled Output</summary>
+
+```html
+<script setup>
+import { ref } from 'vue'
+import Foo from './Foo.vue'
+
+export default {
+  setup() {
+    const count = ref(1)
+
+    function inc() {
+      count.value++
+    }
+
+    console.log(count.value)
+
+    return {
+      Foo,
+      count,
+      inc
+    }
+  }
+}
+</script>
+
+<template>
+  <Foo :count="count" @click="inc" />
+</template>
+```
+
+**Note:** the SFC compiler also extracts binding metadata from `<script setup>` and use it during template compilation. This is why the template can use `Foo` as a component here even though it's returned from `setup()` instead of registered via `components` option.
+</details>
+
+# Motivation
+
+This proposal has two main goals:
+
+1. Reduce verbosity of Single File Component `<script>` by directly exposing its context to the template.
+
+    We have a prior proposal for `<script setup>` [here](https://github.com/vuejs/rfcs/blob/sfc-improvements/active-rfcs/0000-sfc-script-setup.md), which is currently implemented (but marked as experimental). The old proposal opted for the `export` syntax so that the code would play well with unused variable checks.
+
+    This proposal takes a different direction based on the premise that we can offer customized linter rules in `eslint-plugin-vue`. This allows us to aim for the most succinct syntax possible.
+
+2. Improve ergonomics of refs with the `ref:` syntax sugar.
+
+    Ever since the introduction of the Composition API, one of the primary unresolved questions is the use of refs vs. reactive objects. It can be cumbersome to use `.value` everywhere, and it is easy to miss if not using a type system. Some users specifically lean towards using `reactive()` exclusively so that they don't have to deal with refs.
+
+    The existence of ref is mostly a design trade-off due to the constraints of the language we are working with: JavaScript. JavaScript does not provide a native way to pass reactive bindings around without wrapping it with an object. This means that **it is impossible to use refs like normal variable bindings without altering or augmenting JavaScript semantics.**
+
+    - There has been a [proposal for adding native refs to JavaScript](https://github.com/rbuckton/proposal-refs), but it was designed to address a slightly different problem and doesn't seem to have received much attention.
+
+    - A prominent example of altering JavaScript semantics in return for succinct syntax is [Svelte](https://svelte/). It [appropriates a number of JavaScript syntax to express framework-specific behavior](#svelte-syntax-details).
+
+    In the past, we have tried to stick to strict JavaScript semantics as much as possible. Deviating from standard JavaScript semantics has number of [drawbacks](](#drawbacks)), but we believe there is room for a pragmatic trade-off where "breaking out of the box" a little bit can result in substantial improvements in developer experience.
+
+# Detailed design
+
+## `<script setup>`
+
+To opt-in to the syntax, add the `setup` attribute to the `<script>` block:
+
+```html
+<script setup>
+// syntax enabled
+</script>
+```
+
+### Top level bindings are exposed to template
+
+Any top-level bindings (both variables and imports) declared inside `<script setup>` are directly exposed to the template render context:
+
+```html
+<script setup>
+import Foo from './Foo.vue'
+const msg = 'Hello!'
+</script>
+
+<template>
+  <Foo>{{ msg }}</Foo>
+</template>
+```
+
+<details>
+<summary>Compiled Output</summary>
+
+```html
+<script>
+import Foo from './Foo.vue'
+
+export default {
+  setup() {
+    const msg = 'Hello!'
+
+    return {
+      Foo,
+      msg
+    }
+  }
+}
+</script>
+
+<template>
+  <Foo>{{ msg }}</Foo>
+</template>
+```
+
+**Note:** The SFC compiler also extracts binding metadata from `<script setup>` and use it during template compilation. Therefore in the template, `Foo` can be used as a component even though it's returned from `setup()` instead of registered via `components` option.
+</details>
+
+### Setup Signature
+
+The value of the `setup` attribute will be used as the arguments of the `setup()` function:
+
+```html
+<script setup="props, { emit }">
+console.log(props.msg)
+emit('foo')
+</script>
+```
+
+<details>
+<summary>Compiled Output</summary>
+
+```html
+<script>
+export default {
+  setup(props, { emit }) {
+    console.log(props.msg)
+    emit('foo')
+  }
+}
+</script>
+```
+</details>
+
+### Declaring Component Options
+
+`export default` can still be used inside `<script setup>` for declaring component options such as props. Note that the exported expression will be hoisted out of `setup()` scope so it won't be able to reference variables declared in `<script setup>` (a compile error will be emitted in this case).
+
+```html
+<script setup="props">
+export default {
+  props: {
+    msg: String
+  }
+}
+
+console.log(props.msg)
+</script>
+```
+
+<details>
+<summary>Compiled Output</summary>
+
+```html
+<script>
+export default {
+  ...({
+    props: {
+      msg: String
+    }
+  }),
+  setup(props) {
+    console.log(props.msg)
+  }
+}
+</script>
+```
+</details>
+
+### Top level await
+
+Top level `await` can be used inside `<script setup>`. The resulting `setup()` function will be made `async`:
+
+```html
+<script setup>
+const post = await fetch(`/api/post/1`).then(r => r.json())
+</script>
+```
+
+<details>
+<summary>Compiled Output</summary>
+
+```html
+<script>
+export default {
+  async setup() {
+    const post = await fetch(`/api/post/1`).then(r => r.json())
+
+    return { post }
+  }
+}
+</script>
+```
+</details>
+
+## Ref Syntax
+
+Code inside `<script setup>` can use a special `ref:` declaration to declare variables that can be used as a normal variable, but are compiled into refs:
+
+```html
+<script setup>
+ref: count = 0
+
+function inc() {
+  count++
+}
+</script>
+
+<template>
+  <button @click="inc">{{ count }}</button>
+</template>
+```
+
+`ref: count = 0` is a [labeled statement](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/label) which is syntactically valid in both JS/TS. However, we are using it as a variable declaration here. The compiler will:
+
+1. Convert it to a proper variable declaration
+2. Wrap its initial value with `ref()`
+3. Rewrite all references to `count` into `count.value`.
+
+<details>
+<summary>Compiled Output</summary>
+
+```js
+import { ref } from 'vue'
+
+export default {
+  setup() {
+    const count = ref(0)
+
+    function inc() {
+      count.value++
+    }
+
+    return {
+      count,
+      inc
+    }
+  }
+}
+```
+</details>
+<p></p>
+
+Note that the syntax is opt-in: all Composition APIs can be used inside `<script setup>` without ref sugar:
+
+```html
+<script setup>
+import { ref } from 'vue'
+
+const count = ref(0)
+
+function inc() {
+  count.value++
+}
+</script>
+
+<template>
+  <button @click="inc">{{ count }}</button>
+</template>
+```
+
+### Accessing Raw Ref
+
+It is common for an external composition function to expect a raw ref object as argument, so we need a way to access the raw underlying ref object for bindings declared via `ref:`. To deal with that, every `ref:` binding will have a corresponding `$`-prefixed counter part that exposes the raw ref:
+
+```js
+ref: count = 1
+console.log($count.value) // 1
+
+$count.value++
+console.log(count) // 2
+
+watch($count, newCount => {
+  console.log('new count is: ', newCount)
+})
+```
+
+<details>
+<summary>Compiled Output</summary>
+
+```js
+const count = ref(1)
+console.log(count.value) // 1
+
+count.value++
+console.log(count.value) // 2
+
+watch(count, newCount => {
+  console.log('new count is: ', newCount)
+})
+```
+</details>
+
+### Interaction with Non-Literals
+
+`ref:` will wrap assignment values with `ref()`. If the value is already a ref, it will be returned as-is. This means we can use `ref:` with any function that returns a ref, for example `computed`:
+
+```js
+import { computed } from 'vue'
+
+ref: count = 0
+ref: plusOne = computed(() => count + 1)
+console.log(plusOne) // 1
+```
+
+<details>
+<summary>Compiled Output</summary>
+
+```js
+import { computed, ref } from 'vue'
+
+const count = ref(0)
+// `ref()` around `computed()` is a no-op here since return value
+// from `computed()` is already a ref.
+const plusOne = ref(computed(() => count.value + 1))
+```
+</details>
+<p></p>
+
+Or, any custom composition function that returns a ref:
+
+```js
+import { useMyRef } from './composables'
+
+ref: myRef = useMyRef()
+console.log(myRef) // no need for .value
+```
+
+<details>
+<summary>Compiled Output</summary>
+
+```js
+import { useMyRef } from './composables'
+import { ref } from 'vue'
+
+// if useMyRef() returns a ref, it will be untouched
+// otherwise it's wrapped into a ref
+const myRef = ref(useMyRef())
+console.log(myRef.value)
+```
+</details>
+<p></p>
+
+**Note:** if using TypeScript, this behavior creates a typing mismatch which we will discuss in [TypeScript Integration](#typescript-integration) below.
+
+### Destructuring
+
+It is common for a composition function to return an object of refs. To declare multiple ref bindings with destructuring, we can use [Destructuring Assignment](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment):
+
+```js
+ref: ({ x, y } = useMouse())
+```
+
+<details>
+<summary>Compiled Output</summary>
+
+```js
+import { ref } from 'vue'
+
+const { x: __x, y: __x } = useMouse()
+const x = ref(__x)
+const y = toRef(__y)
+```
+</details>
+<p></p>
+
+**Note:** object destructuring must be wrapped in parens - this is JavaScript's own syntax requirement to avoid ambiguity with a block statement.
+
+## TypeScript Integration
+
+### Typing props, slots, and emit
+
+To type setup arguments like `props`, `slots` and `emit`, simply declare them:
+
+```html
+<script setup="props, { emit, slots }" lang="ts">
+import { VNode } from 'vue'
+
+// declare props using TypeScript syntax
+// this will be auto compiled into runtime equivalent!
+declare const props: {
+  msg: string
+}
+
+// declare allowed emit signatures via overload
+declare function emit(e: 'add', msg: string): void
+declare function emit(e: 'remove', id: number): void
+
+// you can even declare slot types
+declare const slots: {
+  default: () => VNode[]
+}
+
+emit('add', props.msg)
+</script>
+```
+
+Runtime props and emits declaration is automatically generated from TS typing to remove the need of double declaration and still ensure correct runtime behavior. 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.
+
+<details>
+<summary>Compile Output</summary>
+
+```html
+<script lang="ts">
+import { VNode, defineComponent } from 'vue'
+
+declare function __emit__(e: 'add', msg: string): void
+declare function __emit__(e: 'remove', id: number): void
+
+declare const slots: {
+  default: () => VNode[]
+}
+
+export default defineComponent({
+  // runtime declaration for props
+  props: {
+    msg: { type: String, required: true }
+  } as unknown as undefined,
+
+  // runtime declaration for emits
+  emits: ["add"] as unknown as undefined,
+
+  setup(props: { msg: string }, { emit }: {
+    emit: typeof __emit__,
+    slots: slots,
+    attrs: Record<string, any>
+  }) {
+    emit('add', props.msg)
+    return {}
+  }
+})
+</script>
+```
+
+Details on runtime props generation:
+
+- 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.
+</details>
+
+### Ref Declaration and Raw Ref Access
+
+Unlike normal variable declarations, the `ref:` syntax has some special behavior in terms of typing:
+
+- The declared variable always has the raw value type, regardless of whether the assigned value is a `Ref` type or not (always unwraps)
+
+- The accompanying `$`-prefixed raw access variable always has a `Ref` type. If the right hand side value type already extends `Ref`, it will be used as-is; otherwise it will be wrapped as `Ref<T>`.
+
+The following table demonstrates the resulting types of different usage:
+
+| source | resulting type for `count` | resulting type for `$count` |
+|--------|----------------------------|-----------------------------|
+|`ref: count = 1`|`number`|`Ref<number>`|
+|`ref: count = ref(1)`|`number`|`Ref<number>`|
+|`ref: count = computed(() => 1)`|`number`|`ComputedRef<number>`|
+|`ref: count = computed({ get:()=>1, set:_=>_ })`|`number`|`WritableComputedRef<number>`|
+
+How to support this in Vetur is [discussed in the appendix](#ref-typescript-support-implementation-details).
+
+## Usage alongside normal `<script>`
+
+There are some cases where the code must be executed in the module scope, for example:
+
+- Declaring named exports
+
+- Global side effects that should only execute once.
+
+In such cases, a normal `<script>` block can be used alongside `<script setup>`:
+
+```html
+<script>
+performGlobalSideEffect()
+
+// this can be imported as `import { named } from './*.vue'`
+export const named = 1
+</script>
+
+<script setup>
+let count = 0
+</script>
+```
+
+<details>
+<summary>Compile Output</summary>
+
+```js
+import { ref } from 'vue'
+
+performGlobalSideEffect()
+
+export const named = 1
+
+export default {
+  setup() {
+    const count = ref(0)
+    return {
+      count
+    }
+  }
+}
+```
+</details>
+
+## 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
+
+## Non-standard semantics
+
+Some users may have strong aversion against non-standard semantics in their code. Many of the Vue team members held such concerns as well. However, consider that:
+
+- Single file components look like HTML but isn't actually HTML. It already has its own required structure and implied behavior on how it works as a Vue component. When you see a `*.vue` file, you know it works differently from plain HTML.
+
+- TypeScript isn't a standard. It's a proprietary superset that extends JavaScript.
+
+- Decorators has struggled to advance into the spec, yet is being widely used and Angular is completely built on top of it.
+
+Granted, adding non-standard semantics to JavaScript still creates added learning cost and mental overhead, so we should carefully evaluate the trade-offs of each addition.
+
+With that in mind, we believe `ref:`'s ergonomics value easily outweighs the cost. This is also why we are limiting this proposal to `ref:` only, since ref access is the only problem that requires alternative semantics to solve.
+
+It can also be argued that the `ref:` syntax isn't far too removed from standard JavaScript. The following code is actually valid JavaScript in non-strict mode - if you copy it into an `.html` file, it will run as expected:
+
+```html
+<script>
+ref: count = 0
+console.log(count)
+</script>
+```
+
+## Requires dedicated tooling support
+
+Appropriating the labeled statement syntax creates a semantic mismatch that leads to integration issues with tooling (linter, TypeScript, IDE support).
+
+This was also one of the primary reservations we had about Svelte 3's design when it was initially proposed. However since then, the Svelte team has managed to provide good tooling/IDE support via its [language tools](https://github.com/sveltejs/language-tools), even for TypeScript.
+
+Vue's single file component also already requires dedicated tooling like `eslint-plugin-vue` and Vetur. The team has already discussed the technical feasibility of providing such support and there should be no hard technical blocks to make it work. We are confident that we can provide:
+
+- Special syntax highlight of `ref:` declared variables in Vetur (so that it's more obvious it's a reactive variable)
+- Proper type check via Vetur and dedicated command line checker
+- Proper linting via `eslint-plugin-vue`
+
+## Extracting in-component logic
+
+The `ref:` syntax sugar is only available inside single file components. Different syntax in and out of components makes it difficult to extract and reuse cross-component logic from existing components.
+
+This is still an issue for Svelte, since Svelte compilation strategy only works inside Svelte components. The generated code assumes a component context and isn't human-maintainable.
+
+In Vue's case, what we are proposing here is a very thin syntax sugar on top of idiomatic Composition API code. The most important thing to note here is that the code written with the sugar can be easily de-sugared into what a developer would have written without the sugar, and extracted into external JavaScript files for composition.
+
+Given a piece of code written using the `ref:` sugar, the workflow of extracting it into an external composition function could be:
+
+1. Select code range for the code to be extracted
+2. In VSCode command input: `>vetur de-sugar ref usage'
+3. Code gets de-sugared and saved to clipboard
+4. Paste code into external file and wrap into an exported function
+5. Import the function in original file and replace original code.
+
+# Alternatives
+
+## Comment-based syntax
+
+```html
+<script setup>
+import Foo from './Foo.vue'
+import { computed } from 'vue'
+
+// @ref
+let count = 1
+
+function inc() {
+  count++
+}
+</script>
+
+<template>
+  <Foo :count="count" @click="inc" />
+</template>
+```
+
+## Other related proposals
+
+- https://github.com/vuejs/rfcs/pull/182 (current `<script setup>` implementation)
+- https://github.com/vuejs/rfcs/pull/213
+- https://github.com/vuejs/rfcs/pull/214
+
+# Adoption strategy
+
+This feature is opt-in. Existing SFC usage is unaffected.
+
+# Unresolved questions
+
+## Ref Usage in Nested Function Scopes
+
+Technically, `ref:` doesn't have to be limited to root level scope and can be used anywhere `let` declarations can be used, including nested function scope:
+
+```js
+function useMouse() {
+  ref: x = 0
+  ref: y = 0
+
+  function update(e) {
+    x = e.pageX
+    y = e.pageY
+  }
+
+  onMounted(() => window.addEventListener('mousemove', update))
+  onUnmounted(() => window.removeEventListener('mousemove', update))
+
+  return {
+    x: $x,
+    y: $y
+  }
+}
+```
+
+<details>
+<summary>Compiled Output</summary>
+
+```js
+function useMouse() {
+  const x = ref(0)
+  const y = ref(0)
+
+  function update(e) {
+    x.value = e.pageX
+    y.value = e.pageY
+  }
+
+  onMounted(() => window.addEventListener('mousemove', update))
+  onUnmounted(() => window.removeEventListener('mousemove', update))
+
+  return {
+    x,
+    y
+  }
+}
+```
+</details>
+<p></p>
+
+This will make the compilation (and accompanying linter / language service support) more complicated - I'm not sure if it's better to limit `ref:` usage to top scope bindings only.
+
+# Appendix
+
+## 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) {
+  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)
+}
+```
+
+## Ref TypeScript Support Implementation Details
+
+There are two issues that prevent `ref:` from working out of the box with TypeScript. Given the following code:
+
+```ts
+ref: count = x
+```
+
+1. TS won't know `count` should be treated as a local variable
+2. If `x` has type `Ref<T>`, there will be a type mismatch since we expect to use `count` as `T`.
+
+The general idea is to pre-transform the code into alternative TypeScript for type checking only (different from runtime-oriented output), get the diagnostics, and map them back. This will be performed by Vetur for IDE intellisense, and via a dedicated command line tool for type checking `*.vue` files (e.g. VTI or `@vuedx/typecheck`).
+
+Example
+
+```ts
+// source
+ref: count = x
+
+// transformed
+import { ref, unref } from 'vue'
+
+let count = unref(x)
+let $count = ref(x)
+```
+
+`ref` and `unref` here are used solely for type conversion purposes since their signatures are:
+
+```ts
+function ref<T>(value: T): T extends Ref ? T : Ref<T>
+function unref<T>(value: T): T extends Ref<infer V> ? V : T
+```
+
+For destructuring:
+
+```ts
+// source
+ref: ({ foo, bar } = useX())
+
+// transformed
+import { ref, unref } from 'vue'
+
+const { foo: __foo, bar: __bar } = useX()
+let foo = unref(__foo)
+let $foo = ref(__foo)
+let bar = unref(__bar)
+let $bar = ref(__bar)
+```
+
+## Svelte Syntax Details
+
+- `export` is used to created component props [[details](https://svelte.dev/docs#1_export_creates_a_component_prop)]
+
+- `let` bindings are considered reactive (invalidation calls are automatically injected after assignments to `let` bindings during compilation). [[details](https://svelte.dev/docs#2_Assignments_are_reactive)]
+
+- Labeled statements starting with `$` are used to denote computed values / reactive statements. [[details](https://svelte.dev/docs#3_$_marks_a_statement_as_reactive)]
+
+- Imported svelte stores (the loose equivalent of a ref in Vue) can be used like a normal variable by using its `$`-prefixed counterpart. [[details](https://svelte.dev/docs#4_Prefix_stores_with_$_to_access_their_values)]

From 2d1bb37b0e68c66b4f758631658b8f3584df495d Mon Sep 17 00:00:00 2001
From: Evan You <yyx990803@gmail.com>
Date: Sun, 1 Nov 2020 18:22:26 -0500
Subject: [PATCH 02/20] edits

- Provide separate examples for `<script setup>` and ref sugar
- Add "yet another way of doing things" in drawbacks
---
 active-rfcs/0000-script-setup.md | 81 ++++++++++++++++++++++++++++----
 1 file changed, 71 insertions(+), 10 deletions(-)

diff --git a/active-rfcs/0000-script-setup.md b/active-rfcs/0000-script-setup.md
index 48611985..22f67170 100644
--- a/active-rfcs/0000-script-setup.md
+++ b/active-rfcs/0000-script-setup.md
@@ -13,11 +13,59 @@
 
 # Basic example
 
+## 1. `<script setup>` now directly exposes top level bindings to template
+
 ```html
 <script setup>
-// imported components are directly usable in template
+// imported components are also directly usable in template
 import Foo from './Foo.vue'
+import { ref } from 'vue'
+
+// write Composition API code just like in a normal setup()
+// but no need to manually return everything
+const count = ref(0)
+const inc = () => { count.value++ }
+</script>
 
+<template>
+  <Foo :count="count" @click="inc" />
+</template>
+```
+
+<details>
+<summary>Compiled Output</summary>
+
+```html
+<script setup>
+import Foo from './Foo.vue'
+import { ref } from 'vue'
+
+export default {
+  setup() {
+    const count = ref(1)
+    const inc = () => { count.value++ }
+
+    return {
+      Foo, // see note below
+      count,
+      inc
+    }
+  }
+}
+</script>
+
+<template>
+  <Foo :count="count" @click="inc" />
+</template>
+```
+
+**Note:** the SFC compiler also extracts binding metadata from `<script setup>` and use it during template compilation. This is why the template can use `Foo` as a component here even though it's returned from `setup()` instead of registered via `components` option.
+</details>
+
+## 2. `ref:` sugar makes ref usage more succinct
+
+```html
+<script setup>
 // declaring a variable that compiles to a ref
 ref: count = 1
 
@@ -31,7 +79,7 @@ console.log($count.value)
 </script>
 
 <template>
-  <Foo :count="count" @click="inc" />
+  <button @click="inc">{{ count }}</button>
 </template>
 ```
 
@@ -41,7 +89,6 @@ console.log($count.value)
 ```html
 <script setup>
 import { ref } from 'vue'
-import Foo from './Foo.vue'
 
 export default {
   setup() {
@@ -54,7 +101,6 @@ export default {
     console.log(count.value)
 
     return {
-      Foo,
       count,
       inc
     }
@@ -63,11 +109,9 @@ export default {
 </script>
 
 <template>
-  <Foo :count="count" @click="inc" />
+  <button @click="inc">{{ count }}</button>
 </template>
 ```
-
-**Note:** the SFC compiler also extracts binding metadata from `<script setup>` and use it during template compilation. This is why the template can use `Foo` as a component here even though it's returned from `setup()` instead of registered via `components` option.
 </details>
 
 # Motivation
@@ -558,7 +602,11 @@ Some users may have strong aversion against non-standard semantics in their code
 
 - Single file components look like HTML but isn't actually HTML. It already has its own required structure and implied behavior on how it works as a Vue component. When you see a `*.vue` file, you know it works differently from plain HTML.
 
-- TypeScript isn't a standard. It's a proprietary superset that extends JavaScript.
+- Vue templates are syntactically valid HTML, but the directives are essentially syntax extensions to express framework-specific intent.
+
+- JSX has a spec, but isn't a standard. It's a non-standard syntax extension to JavaScript.
+
+- TypeScript isn't a standard. It's a proprietary superset of JavaScript.
 
 - Decorators has struggled to advance into the spec, yet is being widely used and Angular is completely built on top of it.
 
@@ -575,6 +623,19 @@ console.log(count)
 </script>
 ```
 
+## Yet Another Way of Doing Things
+
+Some may think that Vue already has Options API, Composition API, and Class API (outside of core, as a library) - and this RFC is adding yet another way of authoring a component. This is a valid concern, but it does not warrant an instant dismissal. When we talk about the drawbacks of "different ways of doing the same thing", the more fundamental issue is the learning cost incurred when a user encounters code written in another format he/she is not familiar with. It is therefore important to evaluate the addition based on the trade-off between:
+
+- How much benefit does the new way provide?
+- How much learning cost does the new way introduce?
+
+This is what we did with the Composition API because we believed the scaling benefits provided by Composition API outweighs its learning cost.
+
+Unlike the relatively significant paradigm difference between Options API and Composition API, this RFC is merely syntax sugar with the primary goal of reducing verbosity. It does not fundamentally alter the mental model. Without the ref sugar, Composition API code inside `<script setup>` will be 100% the same with normal Composition API usage (except for the lack of the return object, which is tedious and unnecessary in the first place). The `ref:` sugar is an extension of the ref concept: for a user with prior knowledge of Composition API, it shouldn't be difficult to quickly understand how it works.
+
+That is to say - the syntax proposed in this RFC will not make the code more difficult to understand for someone who already knows Composition API. The initial time needed for a user to learn the syntax should be trivial compared to the improved DX in the long run.
+
 ## Requires dedicated tooling support
 
 Appropriating the labeled statement syntax creates a semantic mismatch that leads to integration issues with tooling (linter, TypeScript, IDE support).
@@ -599,8 +660,8 @@ Given a piece of code written using the `ref:` sugar, the workflow of extracting
 
 1. Select code range for the code to be extracted
 2. In VSCode command input: `>vetur de-sugar ref usage'
-3. Code gets de-sugared and saved to clipboard
-4. Paste code into external file and wrap into an exported function
+3. Code gets de-sugared
+4. Cut-paste code into external file and wrap into an exported function
 5. Import the function in original file and replace original code.
 
 # Alternatives

From e54312c9ea9226cb539cbd85858469f5e3629af5 Mon Sep 17 00:00:00 2001
From: Evan You <yyx990803@gmail.com>
Date: Mon, 9 Nov 2020 12:04:50 -0500
Subject: [PATCH 03/20] reduce scope to script setup only

---
 active-rfcs/0000-script-setup.md | 506 +++----------------------------
 1 file changed, 40 insertions(+), 466 deletions(-)

diff --git a/active-rfcs/0000-script-setup.md b/active-rfcs/0000-script-setup.md
index 22f67170..7997f461 100644
--- a/active-rfcs/0000-script-setup.md
+++ b/active-rfcs/0000-script-setup.md
@@ -5,16 +5,12 @@
 
 # Summary
 
-- Introduce a new script type in Single File Components: `<script setup>`, which exposes all its top level bindings to the template.
+Introduce a new script type in Single File Components: `<script setup>`, which exposes all its top level bindings to the template.
 
-- Introduce a compiler-based syntax sugar for using refs without `.value` inside `<script setup>`.
-
-- **Note:** this is intended to replace the current `<script setup>` as proposed in [#182](https://github.com/vuejs/rfcs/pull/182).
+**Note:** this is intended to replace the current `<script setup>` as proposed in [#182](https://github.com/vuejs/rfcs/pull/182).
 
 # Basic example
 
-## 1. `<script setup>` now directly exposes top level bindings to template
-
 ```html
 <script setup>
 // imported components are also directly usable in template
@@ -62,79 +58,13 @@ export default {
 **Note:** the SFC compiler also extracts binding metadata from `<script setup>` and use it during template compilation. This is why the template can use `Foo` as a component here even though it's returned from `setup()` instead of registered via `components` option.
 </details>
 
-## 2. `ref:` sugar makes ref usage more succinct
-
-```html
-<script setup>
-// declaring a variable that compiles to a ref
-ref: count = 1
-
-function inc() {
-  // the variable can be used like a plain value
-  count++
-}
-
-// access the raw ref object by prefixing with $
-console.log($count.value)
-</script>
-
-<template>
-  <button @click="inc">{{ count }}</button>
-</template>
-```
-
-<details>
-<summary>Compiled Output</summary>
-
-```html
-<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>
-```
-</details>
-
 # Motivation
 
-This proposal has two main goals:
-
-1. Reduce verbosity of Single File Component `<script>` by directly exposing its context to the template.
-
-    We have a prior proposal for `<script setup>` [here](https://github.com/vuejs/rfcs/blob/sfc-improvements/active-rfcs/0000-sfc-script-setup.md), which is currently implemented (but marked as experimental). The old proposal opted for the `export` syntax so that the code would play well with unused variable checks.
-
-    This proposal takes a different direction based on the premise that we can offer customized linter rules in `eslint-plugin-vue`. This allows us to aim for the most succinct syntax possible.
+This proposal's main goal is reducing the verbosity of Composition API usage inside Single File Components (SFCs) by directly exposing the context of `<script setup>` to the template.
 
-2. Improve ergonomics of refs with the `ref:` syntax sugar.
+We have a prior proposal for `<script setup>` [here](https://github.com/vuejs/rfcs/blob/sfc-improvements/active-rfcs/0000-sfc-script-setup.md), which is currently implemented (but marked as experimental). The old proposal opted for the `export` syntax so that the code would play well with unused variable checks.
 
-    Ever since the introduction of the Composition API, one of the primary unresolved questions is the use of refs vs. reactive objects. It can be cumbersome to use `.value` everywhere, and it is easy to miss if not using a type system. Some users specifically lean towards using `reactive()` exclusively so that they don't have to deal with refs.
-
-    The existence of ref is mostly a design trade-off due to the constraints of the language we are working with: JavaScript. JavaScript does not provide a native way to pass reactive bindings around without wrapping it with an object. This means that **it is impossible to use refs like normal variable bindings without altering or augmenting JavaScript semantics.**
-
-    - There has been a [proposal for adding native refs to JavaScript](https://github.com/rbuckton/proposal-refs), but it was designed to address a slightly different problem and doesn't seem to have received much attention.
-
-    - A prominent example of altering JavaScript semantics in return for succinct syntax is [Svelte](https://svelte/). It [appropriates a number of JavaScript syntax to express framework-specific behavior](#svelte-syntax-details).
-
-    In the past, we have tried to stick to strict JavaScript semantics as much as possible. Deviating from standard JavaScript semantics has number of [drawbacks](](#drawbacks)), but we believe there is room for a pragmatic trade-off where "breaking out of the box" a little bit can result in substantial improvements in developer experience.
+This proposal takes a different direction based on the premise that we can offer customized linter rules in `eslint-plugin-vue`. This allows us to aim for the most succinct syntax possible.
 
 # Detailed design
 
@@ -189,6 +119,34 @@ export default {
 
 **Note:** The SFC compiler also extracts binding metadata from `<script setup>` and use it during template compilation. Therefore in the template, `Foo` can be used as a component even though it's returned from `setup()` instead of registered via `components` option.
 </details>
+<p></p>
+
+### Scoping Mental Model
+
+Some users may be concerned that it is no longer clear what variables are exposed to the template vs. those that are not. However, it can be argued that there is no practical benefits in being able to tell this.
+
+In the past we have always considered the `<script>` and `<template>` parts of an SFC to be separate parts that need an explicit protocol to be "connected". It does feel different to have this separation blurred. However, if we switch the scoping mental model to view an SFC as returning a render function from the `setup()` closure instead:
+
+```js
+function setup() {
+  let a = 1
+  let b = a + 1
+
+  // the returned function has access to everything inside setup()
+  // however it may or may not use all of them.
+  return () => {
+    return h('div', b)
+  }
+}
+```
+
+This does require different handling when linting for unused variables, but SFCs already require the usage of `eslint-plugin-vue` which can be made to adapt to this new scoping model.
+
+### Closed by Default
+
+In a Vue component, everything exposed to the template is implicitly exposed on the component instance, which can be retrieved by a parent component via template refs. That is to say, up to this point the **template render context** and the **imperative public interface** of a component is one and the same. We have found this to be problematic because the two use cases do not always align perfectly. In fact, most of the time we are over-exposing on the public interface front. This is why we are discussing an explicit way to define a component's imperative public interface in https://github.com/vuejs/rfcs/pull/210.
+
+`<script setup>` as proposed in this RFC, if following current behavior, will be vastly over-exposing on the imperative public interface, therefore a component using `<script setup>` will be **closed by default**. That is to say, its public imperative interface will be an empty object unless bindings are explicitly exposed. How to explicitly expose imperative public interface will be finalized in https://github.com/vuejs/rfcs/pull/210.
 
 ### Setup Signature
 
@@ -277,183 +235,8 @@ export default {
 ```
 </details>
 
-## Ref Syntax
-
-Code inside `<script setup>` can use a special `ref:` declaration to declare variables that can be used as a normal variable, but are compiled into refs:
-
-```html
-<script setup>
-ref: count = 0
-
-function inc() {
-  count++
-}
-</script>
-
-<template>
-  <button @click="inc">{{ count }}</button>
-</template>
-```
-
-`ref: count = 0` is a [labeled statement](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/label) which is syntactically valid in both JS/TS. However, we are using it as a variable declaration here. The compiler will:
-
-1. Convert it to a proper variable declaration
-2. Wrap its initial value with `ref()`
-3. Rewrite all references to `count` into `count.value`.
-
-<details>
-<summary>Compiled Output</summary>
-
-```js
-import { ref } from 'vue'
-
-export default {
-  setup() {
-    const count = ref(0)
-
-    function inc() {
-      count.value++
-    }
-
-    return {
-      count,
-      inc
-    }
-  }
-}
-```
-</details>
-<p></p>
-
-Note that the syntax is opt-in: all Composition APIs can be used inside `<script setup>` without ref sugar:
-
-```html
-<script setup>
-import { ref } from 'vue'
-
-const count = ref(0)
-
-function inc() {
-  count.value++
-}
-</script>
-
-<template>
-  <button @click="inc">{{ count }}</button>
-</template>
-```
-
-### Accessing Raw Ref
-
-It is common for an external composition function to expect a raw ref object as argument, so we need a way to access the raw underlying ref object for bindings declared via `ref:`. To deal with that, every `ref:` binding will have a corresponding `$`-prefixed counter part that exposes the raw ref:
-
-```js
-ref: count = 1
-console.log($count.value) // 1
-
-$count.value++
-console.log(count) // 2
-
-watch($count, newCount => {
-  console.log('new count is: ', newCount)
-})
-```
-
-<details>
-<summary>Compiled Output</summary>
-
-```js
-const count = ref(1)
-console.log(count.value) // 1
-
-count.value++
-console.log(count.value) // 2
-
-watch(count, newCount => {
-  console.log('new count is: ', newCount)
-})
-```
-</details>
-
-### Interaction with Non-Literals
-
-`ref:` will wrap assignment values with `ref()`. If the value is already a ref, it will be returned as-is. This means we can use `ref:` with any function that returns a ref, for example `computed`:
-
-```js
-import { computed } from 'vue'
-
-ref: count = 0
-ref: plusOne = computed(() => count + 1)
-console.log(plusOne) // 1
-```
-
-<details>
-<summary>Compiled Output</summary>
-
-```js
-import { computed, ref } from 'vue'
-
-const count = ref(0)
-// `ref()` around `computed()` is a no-op here since return value
-// from `computed()` is already a ref.
-const plusOne = ref(computed(() => count.value + 1))
-```
-</details>
-<p></p>
-
-Or, any custom composition function that returns a ref:
-
-```js
-import { useMyRef } from './composables'
-
-ref: myRef = useMyRef()
-console.log(myRef) // no need for .value
-```
-
-<details>
-<summary>Compiled Output</summary>
-
-```js
-import { useMyRef } from './composables'
-import { ref } from 'vue'
-
-// if useMyRef() returns a ref, it will be untouched
-// otherwise it's wrapped into a ref
-const myRef = ref(useMyRef())
-console.log(myRef.value)
-```
-</details>
-<p></p>
-
-**Note:** if using TypeScript, this behavior creates a typing mismatch which we will discuss in [TypeScript Integration](#typescript-integration) below.
-
-### Destructuring
-
-It is common for a composition function to return an object of refs. To declare multiple ref bindings with destructuring, we can use [Destructuring Assignment](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment):
-
-```js
-ref: ({ x, y } = useMouse())
-```
-
-<details>
-<summary>Compiled Output</summary>
-
-```js
-import { ref } from 'vue'
-
-const { x: __x, y: __x } = useMouse()
-const x = ref(__x)
-const y = toRef(__y)
-```
-</details>
-<p></p>
-
-**Note:** object destructuring must be wrapped in parens - this is JavaScript's own syntax requirement to avoid ambiguity with a block statement.
-
 ## TypeScript Integration
 
-### Typing props, slots, and emit
-
 To type setup arguments like `props`, `slots` and `emit`, simply declare them:
 
 ```html
@@ -527,25 +310,6 @@ Details on runtime props generation:
 - The emitted code is still TypeScript with valid typing, which can be further processed by other tools.
 </details>
 
-### Ref Declaration and Raw Ref Access
-
-Unlike normal variable declarations, the `ref:` syntax has some special behavior in terms of typing:
-
-- The declared variable always has the raw value type, regardless of whether the assigned value is a `Ref` type or not (always unwraps)
-
-- The accompanying `$`-prefixed raw access variable always has a `Ref` type. If the right hand side value type already extends `Ref`, it will be used as-is; otherwise it will be wrapped as `Ref<T>`.
-
-The following table demonstrates the resulting types of different usage:
-
-| source | resulting type for `count` | resulting type for `$count` |
-|--------|----------------------------|-----------------------------|
-|`ref: count = 1`|`number`|`Ref<number>`|
-|`ref: count = ref(1)`|`number`|`Ref<number>`|
-|`ref: count = computed(() => 1)`|`number`|`ComputedRef<number>`|
-|`ref: count = computed({ get:()=>1, set:_=>_ })`|`number`|`WritableComputedRef<number>`|
-
-How to support this in Vetur is [discussed in the appendix](#ref-typescript-support-implementation-details).
-
 ## Usage alongside normal `<script>`
 
 There are some cases where the code must be executed in the module scope, for example:
@@ -596,101 +360,19 @@ Due to the difference in module execution semantics, code inside `<script setup>
 
 # Drawbacks
 
-## Non-standard semantics
-
-Some users may have strong aversion against non-standard semantics in their code. Many of the Vue team members held such concerns as well. However, consider that:
-
-- Single file components look like HTML but isn't actually HTML. It already has its own required structure and implied behavior on how it works as a Vue component. When you see a `*.vue` file, you know it works differently from plain HTML.
-
-- Vue templates are syntactically valid HTML, but the directives are essentially syntax extensions to express framework-specific intent.
-
-- JSX has a spec, but isn't a standard. It's a non-standard syntax extension to JavaScript.
-
-- TypeScript isn't a standard. It's a proprietary superset of JavaScript.
-
-- Decorators has struggled to advance into the spec, yet is being widely used and Angular is completely built on top of it.
-
-Granted, adding non-standard semantics to JavaScript still creates added learning cost and mental overhead, so we should carefully evaluate the trade-offs of each addition.
-
-With that in mind, we believe `ref:`'s ergonomics value easily outweighs the cost. This is also why we are limiting this proposal to `ref:` only, since ref access is the only problem that requires alternative semantics to solve.
-
-It can also be argued that the `ref:` syntax isn't far too removed from standard JavaScript. The following code is actually valid JavaScript in non-strict mode - if you copy it into an `.html` file, it will run as expected:
-
-```html
-<script>
-ref: count = 0
-console.log(count)
-</script>
-```
-
-## Yet Another Way of Doing Things
-
-Some may think that Vue already has Options API, Composition API, and Class API (outside of core, as a library) - and this RFC is adding yet another way of authoring a component. This is a valid concern, but it does not warrant an instant dismissal. When we talk about the drawbacks of "different ways of doing the same thing", the more fundamental issue is the learning cost incurred when a user encounters code written in another format he/she is not familiar with. It is therefore important to evaluate the addition based on the trade-off between:
-
-- How much benefit does the new way provide?
-- How much learning cost does the new way introduce?
-
-This is what we did with the Composition API because we believed the scaling benefits provided by Composition API outweighs its learning cost.
-
-Unlike the relatively significant paradigm difference between Options API and Composition API, this RFC is merely syntax sugar with the primary goal of reducing verbosity. It does not fundamentally alter the mental model. Without the ref sugar, Composition API code inside `<script setup>` will be 100% the same with normal Composition API usage (except for the lack of the return object, which is tedious and unnecessary in the first place). The `ref:` sugar is an extension of the ref concept: for a user with prior knowledge of Composition API, it shouldn't be difficult to quickly understand how it works.
-
-That is to say - the syntax proposed in this RFC will not make the code more difficult to understand for someone who already knows Composition API. The initial time needed for a user to learn the syntax should be trivial compared to the improved DX in the long run.
-
-## Requires dedicated tooling support
-
-Appropriating the labeled statement syntax creates a semantic mismatch that leads to integration issues with tooling (linter, TypeScript, IDE support).
+## Tooling Compatiblity
 
-This was also one of the primary reservations we had about Svelte 3's design when it was initially proposed. However since then, the Svelte team has managed to provide good tooling/IDE support via its [language tools](https://github.com/sveltejs/language-tools), even for TypeScript.
+This new scoping model will require tooling adjustments in two aspects:
 
-Vue's single file component also already requires dedicated tooling like `eslint-plugin-vue` and Vetur. The team has already discussed the technical feasibility of providing such support and there should be no hard technical blocks to make it work. We are confident that we can provide:
+1. ESLint rules like `no-unused-vars`. We will need a replacement rule in `eslint-plugin-vue` that takes both the `<script setup>` and `<template>` expressions into account.
 
-- Special syntax highlight of `ref:` declared variables in Vetur (so that it's more obvious it's a reactive variable)
-- Proper type check via Vetur and dedicated command line checker
-- Proper linting via `eslint-plugin-vue`
+2. Vetur and other IDEs will need to provide dedicated handling for this new `<script setup>` model in order to provide template expression type checking / props validation, etc.
 
-## Extracting in-component logic
-
-The `ref:` syntax sugar is only available inside single file components. Different syntax in and out of components makes it difficult to extract and reuse cross-component logic from existing components.
-
-This is still an issue for Svelte, since Svelte compilation strategy only works inside Svelte components. The generated code assumes a component context and isn't human-maintainable.
-
-In Vue's case, what we are proposing here is a very thin syntax sugar on top of idiomatic Composition API code. The most important thing to note here is that the code written with the sugar can be easily de-sugared into what a developer would have written without the sugar, and extracted into external JavaScript files for composition.
-
-Given a piece of code written using the `ref:` sugar, the workflow of extracting it into an external composition function could be:
-
-1. Select code range for the code to be extracted
-2. In VSCode command input: `>vetur de-sugar ref usage'
-3. Code gets de-sugared
-4. Cut-paste code into external file and wrap into an exported function
-5. Import the function in original file and replace original code.
+One thing to note is that `<script setup>` syntax should make it easier for tools to analyze available bindings to the template compared to current Options API inside `<script setup>` (especially with mixins). A potential approach is transforming the entire SFC into a TSX file (similar to [svelte2tsx](https://github.com/sveltejs/language-tools/tree/master/packages/svelte2tsx)) for type-checking and refactoring support only.
 
 # Alternatives
 
-## Comment-based syntax
-
-```html
-<script setup>
-import Foo from './Foo.vue'
-import { computed } from 'vue'
-
-// @ref
-let count = 1
-
-function inc() {
-  count++
-}
-</script>
-
-<template>
-  <Foo :count="count" @click="inc" />
-</template>
-```
-
-## Other related proposals
-
-- https://github.com/vuejs/rfcs/pull/182 (current `<script setup>` implementation)
-- https://github.com/vuejs/rfcs/pull/213
-- https://github.com/vuejs/rfcs/pull/214
+https://github.com/vuejs/rfcs/pull/182 (current `<script setup>` implementation)
 
 # Adoption strategy
 
@@ -698,56 +380,7 @@ This feature is opt-in. Existing SFC usage is unaffected.
 
 # Unresolved questions
 
-## Ref Usage in Nested Function Scopes
-
-Technically, `ref:` doesn't have to be limited to root level scope and can be used anywhere `let` declarations can be used, including nested function scope:
-
-```js
-function useMouse() {
-  ref: x = 0
-  ref: y = 0
-
-  function update(e) {
-    x = e.pageX
-    y = e.pageY
-  }
-
-  onMounted(() => window.addEventListener('mousemove', update))
-  onUnmounted(() => window.removeEventListener('mousemove', update))
-
-  return {
-    x: $x,
-    y: $y
-  }
-}
-```
-
-<details>
-<summary>Compiled Output</summary>
-
-```js
-function useMouse() {
-  const x = ref(0)
-  const y = ref(0)
-
-  function update(e) {
-    x.value = e.pageX
-    y.value = e.pageY
-  }
-
-  onMounted(() => window.addEventListener('mousemove', update))
-  onUnmounted(() => window.removeEventListener('mousemove', update))
-
-  return {
-    x,
-    y
-  }
-}
-```
-</details>
-<p></p>
-
-This will make the compilation (and accompanying linter / language service support) more complicated - I'm not sure if it's better to limit `ref:` usage to top scope bindings only.
+This RFC depends on https://github.com/vuejs/rfcs/pull/210 being resolved first.
 
 # Appendix
 
@@ -821,62 +454,3 @@ function render(_ctx, _cache, $setup, $props, $data) {
   return createVNode('div', null, $setup.foo + $props.bar)
 }
 ```
-
-## Ref TypeScript Support Implementation Details
-
-There are two issues that prevent `ref:` from working out of the box with TypeScript. Given the following code:
-
-```ts
-ref: count = x
-```
-
-1. TS won't know `count` should be treated as a local variable
-2. If `x` has type `Ref<T>`, there will be a type mismatch since we expect to use `count` as `T`.
-
-The general idea is to pre-transform the code into alternative TypeScript for type checking only (different from runtime-oriented output), get the diagnostics, and map them back. This will be performed by Vetur for IDE intellisense, and via a dedicated command line tool for type checking `*.vue` files (e.g. VTI or `@vuedx/typecheck`).
-
-Example
-
-```ts
-// source
-ref: count = x
-
-// transformed
-import { ref, unref } from 'vue'
-
-let count = unref(x)
-let $count = ref(x)
-```
-
-`ref` and `unref` here are used solely for type conversion purposes since their signatures are:
-
-```ts
-function ref<T>(value: T): T extends Ref ? T : Ref<T>
-function unref<T>(value: T): T extends Ref<infer V> ? V : T
-```
-
-For destructuring:
-
-```ts
-// source
-ref: ({ foo, bar } = useX())
-
-// transformed
-import { ref, unref } from 'vue'
-
-const { foo: __foo, bar: __bar } = useX()
-let foo = unref(__foo)
-let $foo = ref(__foo)
-let bar = unref(__bar)
-let $bar = ref(__bar)
-```
-
-## Svelte Syntax Details
-
-- `export` is used to created component props [[details](https://svelte.dev/docs#1_export_creates_a_component_prop)]
-
-- `let` bindings are considered reactive (invalidation calls are automatically injected after assignments to `let` bindings during compilation). [[details](https://svelte.dev/docs#2_Assignments_are_reactive)]
-
-- Labeled statements starting with `$` are used to denote computed values / reactive statements. [[details](https://svelte.dev/docs#3_$_marks_a_statement_as_reactive)]
-
-- Imported svelte stores (the loose equivalent of a ref in Vue) can be used like a normal variable by using its `$`-prefixed counterpart. [[details](https://svelte.dev/docs#4_Prefix_stores_with_$_to_access_their_values)]

From 395800290853850c0793ed1b33473feeb4c2d3c7 Mon Sep 17 00:00:00 2001
From: Evan You <yyx990803@gmail.com>
Date: Fri, 13 Nov 2020 10:47:20 -0500
Subject: [PATCH 04/20] update script setup per feedback

---
 active-rfcs/0000-script-setup.md | 324 +++++++++++++++----------------
 1 file changed, 162 insertions(+), 162 deletions(-)

diff --git a/active-rfcs/0000-script-setup.md b/active-rfcs/0000-script-setup.md
index 7997f461..16ddc450 100644
--- a/active-rfcs/0000-script-setup.md
+++ b/active-rfcs/0000-script-setup.md
@@ -13,14 +13,16 @@ Introduce a new script type in Single File Components: `<script setup>`, which e
 
 ```html
 <script setup>
-// imported components are also directly usable in template
-import Foo from './Foo.vue'
-import { ref } from 'vue'
-
-// write Composition API code just like in a normal setup()
-// but no need to manually return everything
-const count = ref(0)
-const inc = () => { count.value++ }
+  // imported components are also directly usable in template
+  import Foo from './Foo.vue'
+  import { ref } from 'vue'
+
+  // write Composition API code just like in a normal setup()
+  // but no need to manually return everything
+  const count = ref(0)
+  const inc = () => {
+    count.value++
+  }
 </script>
 
 <template>
@@ -33,21 +35,23 @@ const inc = () => { count.value++ }
 
 ```html
 <script setup>
-import Foo from './Foo.vue'
-import { ref } from 'vue'
-
-export default {
-  setup() {
-    const count = ref(1)
-    const inc = () => { count.value++ }
-
-    return {
-      Foo, // see note below
-      count,
-      inc
-    }
+  import Foo from './Foo.vue'
+  import { ref } from 'vue'
+
+  export default {
+    setup() {
+      const count = ref(1)
+      const inc = () => {
+        count.value++
+      }
+
+      return {
+        Foo, // see note below
+        count,
+        inc,
+      }
+    },
   }
-}
 </script>
 
 <template>
@@ -56,6 +60,7 @@ export default {
 ```
 
 **Note:** the SFC compiler also extracts binding metadata from `<script setup>` and use it during template compilation. This is why the template can use `Foo` as a component here even though it's returned from `setup()` instead of registered via `components` option.
+
 </details>
 
 # Motivation
@@ -74,7 +79,7 @@ To opt-in to the syntax, add the `setup` attribute to the `<script>` block:
 
 ```html
 <script setup>
-// syntax enabled
+  // syntax enabled
 </script>
 ```
 
@@ -84,8 +89,8 @@ Any top-level bindings (both variables and imports) declared inside `<script set
 
 ```html
 <script setup>
-import Foo from './Foo.vue'
-const msg = 'Hello!'
+  import Foo from './Foo.vue'
+  const msg = 'Hello!'
 </script>
 
 <template>
@@ -98,18 +103,18 @@ const msg = 'Hello!'
 
 ```html
 <script>
-import Foo from './Foo.vue'
+  import Foo from './Foo.vue'
 
-export default {
-  setup() {
-    const msg = 'Hello!'
+  export default {
+    setup() {
+      const msg = 'Hello!'
 
-    return {
-      Foo,
-      msg
-    }
+      return {
+        Foo,
+        msg,
+      }
+    },
   }
-}
 </script>
 
 <template>
@@ -118,10 +123,11 @@ export default {
 ```
 
 **Note:** The SFC compiler also extracts binding metadata from `<script setup>` and use it during template compilation. Therefore in the template, `Foo` can be used as a component even though it's returned from `setup()` instead of registered via `components` option.
+
 </details>
 <p></p>
 
-### Scoping Mental Model
+### Scoping mental model
 
 Some users may be concerned that it is no longer clear what variables are exposed to the template vs. those that are not. However, it can be argued that there is no practical benefits in being able to tell this.
 
@@ -140,174 +146,112 @@ function setup() {
 }
 ```
 
+In fact, we have also introduced an [inline template](#inline-template-mode) option that will compile SFCs into this format. By inlining the generated render function inside `setup()` scope, we can directly access in scope variables without having to go through the render proxy. This can lead to decent performance gains.
+
 This does require different handling when linting for unused variables, but SFCs already require the usage of `eslint-plugin-vue` which can be made to adapt to this new scoping model.
 
-### Closed by Default
+### Closed by default
 
 In a Vue component, everything exposed to the template is implicitly exposed on the component instance, which can be retrieved by a parent component via template refs. That is to say, up to this point the **template render context** and the **imperative public interface** of a component is one and the same. We have found this to be problematic because the two use cases do not always align perfectly. In fact, most of the time we are over-exposing on the public interface front. This is why we are discussing an explicit way to define a component's imperative public interface in https://github.com/vuejs/rfcs/pull/210.
 
 `<script setup>` as proposed in this RFC, if following current behavior, will be vastly over-exposing on the imperative public interface, therefore a component using `<script setup>` will be **closed by default**. That is to say, its public imperative interface will be an empty object unless bindings are explicitly exposed. How to explicitly expose imperative public interface will be finalized in https://github.com/vuejs/rfcs/pull/210.
 
-### Setup Signature
+### Declaring options and setup context
 
-The value of the `setup` attribute will be used as the arguments of the `setup()` function:
+In order to declare options like `props` and `emits`, and also receive arguments that are passed to the `setup()` function, we can use the newly introduced `useOptions` API:
 
 ```html
-<script setup="props, { emit }">
-console.log(props.msg)
-emit('foo')
-</script>
-```
+<script setup>
+  import { useOptions } from 'vue'
 
-<details>
-<summary>Compiled Output</summary>
+  const { props, emit, slots, attrs } = useOptions({
+    props: {
+      foo: String,
+    },
+    emits: ['change', 'delete'],
+  })
 
-```html
-<script>
-export default {
-  setup(props, { emit }) {
-    console.log(props.msg)
-    emit('foo')
-  }
-}
+  // setup code
 </script>
 ```
-</details>
-
-### Declaring Component Options
-
-`export default` can still be used inside `<script setup>` for declaring component options such as props. Note that the exported expression will be hoisted out of `setup()` scope so it won't be able to reference variables declared in `<script setup>` (a compile error will be emitted in this case).
-
-```html
-<script setup="props">
-export default {
-  props: {
-    msg: String
-  }
-}
 
-console.log(props.msg)
-</script>
-```
+The return value of `useOptions` is the setup context (2nd argument passed to `setup()`). Note that in current core API, the setup context does not expose `props` - in order to align the concepts, we are updating the setup context to expose `props` as well.
 
-<details>
-<summary>Compiled Output</summary>
+**Compiled output**
 
 ```html
 <script>
-export default {
-  ...({
+  export default {
     props: {
-      msg: String
-    }
-  }),
-  setup(props) {
-    console.log(props.msg)
+      foo: String,
+    },
+    emits: ['change', 'delete'],
+    setup(_, { props, emit, slots, attrs }) {
+      // setup code
+    },
   }
-}
 </script>
 ```
-</details>
 
-### Top level await
+**Additional notes:**
 
-Top level `await` can be used inside `<script setup>`. The resulting `setup()` function will be made `async`:
+- `useOptions` provides type inference similar to `defineComponent`.
 
-```html
-<script setup>
-const post = await fetch(`/api/post/1`).then(r => r.json())
-</script>
-```
+- `useOptions` is a **compiler hint function**: it is compiled away when `<script setup>` is processed. The actual runtime implementation is a no-op and should never be called. Doing so will result in a runtime warning.
 
-<details>
-<summary>Compiled Output</summary>
+- The options passed to `useOptions` will be hoisted out of setup into module scope. Therefore, the options cannot reference local variables declared in setup scope. Doing so will result in a compile error. However, it _can_ reference imported bindings since they are in the module scope as well.
 
-```html
-<script>
-export default {
-  async setup() {
-    const post = await fetch(`/api/post/1`).then(r => r.json())
+### Type-only props/emit declarations
+
+Props and emits can also be declared using pure-type syntax by passing a literal type argument to `useOptions`:
 
-    return { post }
+```ts
+const { props, emit } = useOptions<{
+  props: {
+    foo: string
+    bar?: number
   }
-}
-</script>
+  emit: (e: 'update' | 'delete', id: number) => void
+}>()
 ```
-</details>
 
-## TypeScript Integration
+- `useOptions` can only use either runtime declaration OR type declartion. Using both at the same time will result in a compile error.
 
-To type setup arguments like `props`, `slots` and `emit`, simply declare them:
+- When using type declaration, equivalent runtime declaration is automatically generated from static analysis to remove the need of double declaration and still ensure correct runtime behavior.
 
-```html
-<script setup="props, { emit, slots }" lang="ts">
-import { VNode } from 'vue'
+  - In dev mode, the compiler will try to infer corresponding runtime validation from the types. For example here `foo: String` is inferred from the `foo: string` type. If the type is a reference to an imported type, the inferred result will be `foo: null` (equal to `any` type) since the compiler does not have information of external files.
 
-// declare props using TypeScript syntax
-// this will be auto compiled into runtime equivalent!
-declare const props: {
-  msg: string
-}
+  - In prod mode, the compiler will generate the array format declaration to reduce bundle size (the props here will be compiled into `['msg']`)
 
-// declare allowed emit signatures via overload
-declare function emit(e: 'add', msg: string): void
-declare function emit(e: 'remove', id: number): void
+  - The emitted code is still TypeScript with valid typing, which can be further processed by other tools.
 
-// you can even declare slot types
-declare const slots: {
-  default: () => VNode[]
-}
+- As of now, the type declaration argument must be a literal type to ensure correct static analysis. This can be improved in the future.
+
+### Top level await
 
-emit('add', props.msg)
+Top level `await` can be used inside `<script setup>`. The resulting `setup()` function will be made `async`:
+
+```html
+<script setup>
+  const post = await fetch(`/api/post/1`).then((r) => r.json())
 </script>
 ```
 
-Runtime props and emits declaration is automatically generated from TS typing to remove the need of double declaration and still ensure correct runtime behavior. 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.
-
 <details>
-<summary>Compile Output</summary>
+<summary>Compiled Output</summary>
 
 ```html
-<script lang="ts">
-import { VNode, defineComponent } from 'vue'
-
-declare function __emit__(e: 'add', msg: string): void
-declare function __emit__(e: 'remove', id: number): void
-
-declare const slots: {
-  default: () => VNode[]
-}
+<script>
+  export default {
+    async setup() {
+      const post = await fetch(`/api/post/1`).then((r) => r.json())
 
-export default defineComponent({
-  // runtime declaration for props
-  props: {
-    msg: { type: String, required: true }
-  } as unknown as undefined,
-
-  // runtime declaration for emits
-  emits: ["add"] as unknown as undefined,
-
-  setup(props: { msg: string }, { emit }: {
-    emit: typeof __emit__,
-    slots: slots,
-    attrs: Record<string, any>
-  }) {
-    emit('add', props.msg)
-    return {}
+      return { post }
+    },
   }
-})
 </script>
 ```
 
-Details on runtime props generation:
-
-- 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.
 </details>
 
 ## Usage alongside normal `<script>`
@@ -322,14 +266,14 @@ In such cases, a normal `<script>` block can be used alongside `<script setup>`:
 
 ```html
 <script>
-performGlobalSideEffect()
+  performGlobalSideEffect()
 
-// this can be imported as `import { named } from './*.vue'`
-export const named = 1
+  // this can be imported as `import { named } from './*.vue'`
+  export const named = 1
 </script>
 
 <script setup>
-let count = 0
+  let count = 0
 </script>
 ```
 
@@ -347,11 +291,12 @@ export default {
   setup() {
     const count = ref(0)
     return {
-      count
+      count,
     }
-  }
+  },
 }
 ```
+
 </details>
 
 ## Usage restrictions
@@ -402,6 +347,59 @@ if (descriptor.script || descriptor.scriptSetup) {
 
 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.
 
+## Inline Template Mode
+
+Inline template mode can be enabled via the `inlineTemplate` option:
+
+```js
+compileScript(descriptor, { inlineTemplate: true })
+```
+
+This will compile the SFC template as well and inline it inside the `setup()` function generated from `<script setup>`. Example:
+
+```html
+<script setup>
+  import { ref } from 'vue'
+
+  const count = ref(0)
+
+  function inc() {
+    count.value++
+  }
+</script>
+<template>
+  <button @click="inc">{{ count }}</button>
+</template>
+```
+
+**Compiled to:**
+
+```js
+import { ref, unref, createVNode, toDisplayString } from 'vue'
+
+export default {
+  setup() {
+    const count = ref(0)
+
+    function inc() {
+      count.value++
+    }
+
+    return () => {
+      createVNode(
+        'div',
+        {
+          onClick: inc,
+        },
+        toDisplayString(unref(count))
+      )
+    }
+  },
+}
+```
+
+Note some bindings need to be wrapped with `unref` - the compiler performs some heuristics to avoid this when possible. For example, function declarations and const declarations with literal initial values will not be wrapped with `unref`.
+
 ## 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>`:
@@ -411,7 +409,7 @@ The `SFCScriptBlock` returned by `compiledScript` also exposes a `bindings` obje
 export const foo = 1
 
 export default {
-  props: ['bar']
+  props: ['bar'],
 }
 </script>
 ```
@@ -431,7 +429,7 @@ This object can then be passed to the template compiler:
 import { compile } from '@vue/compiler-dom'
 
 compile(template, {
-  bindingMetadata: bindings
+  bindingMetadata: bindings,
 })
 ```
 
@@ -454,3 +452,5 @@ function render(_ctx, _cache, $setup, $props, $data) {
   return createVNode('div', null, $setup.foo + $props.bar)
 }
 ```
+
+The binding information is also used in inline template mode to generate more efficient code.

From 2dd282e4240ef683106c582b02e2a6e8db206ba7 Mon Sep 17 00:00:00 2001
From: Evan You <yyx990803@gmail.com>
Date: Fri, 13 Nov 2020 17:39:15 -0500
Subject: [PATCH 05/20] useOptions -> defineOptions

---
 active-rfcs/0000-script-setup.md | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/active-rfcs/0000-script-setup.md b/active-rfcs/0000-script-setup.md
index 16ddc450..54ca4a23 100644
--- a/active-rfcs/0000-script-setup.md
+++ b/active-rfcs/0000-script-setup.md
@@ -158,13 +158,13 @@ In a Vue component, everything exposed to the template is implicitly exposed on
 
 ### Declaring options and setup context
 
-In order to declare options like `props` and `emits`, and also receive arguments that are passed to the `setup()` function, we can use the newly introduced `useOptions` API:
+In order to declare options like `props` and `emits`, and also receive arguments that are passed to the `setup()` function, we can use the newly introduced `defineOptions` API:
 
 ```html
 <script setup>
-  import { useOptions } from 'vue'
+  import { defineOptions } from 'vue'
 
-  const { props, emit, slots, attrs } = useOptions({
+  const { props, emit, slots, attrs } = defineOptions({
     props: {
       foo: String,
     },
@@ -175,7 +175,7 @@ In order to declare options like `props` and `emits`, and also receive arguments
 </script>
 ```
 
-The return value of `useOptions` is the setup context (2nd argument passed to `setup()`). Note that in current core API, the setup context does not expose `props` - in order to align the concepts, we are updating the setup context to expose `props` as well.
+The return value of `defineOptions` is the setup context (2nd argument passed to `setup()`). Note that in current core API, the setup context does not expose `props` - in order to align the concepts, we are updating the setup context to expose `props` as well.
 
 **Compiled output**
 
@@ -195,18 +195,18 @@ The return value of `useOptions` is the setup context (2nd argument passed to `s
 
 **Additional notes:**
 
-- `useOptions` provides type inference similar to `defineComponent`.
+- `defineOptions` provides type inference similar to `defineComponent`.
 
-- `useOptions` is a **compiler hint function**: it is compiled away when `<script setup>` is processed. The actual runtime implementation is a no-op and should never be called. Doing so will result in a runtime warning.
+- `defineOptions` is a **compiler hint function**: it is compiled away when `<script setup>` is processed. The actual runtime implementation is a no-op and should never be called. Doing so will result in a runtime warning.
 
-- The options passed to `useOptions` will be hoisted out of setup into module scope. Therefore, the options cannot reference local variables declared in setup scope. Doing so will result in a compile error. However, it _can_ reference imported bindings since they are in the module scope as well.
+- The options passed to `defineOptions` will be hoisted out of setup into module scope. Therefore, the options cannot reference local variables declared in setup scope. Doing so will result in a compile error. However, it _can_ reference imported bindings since they are in the module scope as well.
 
 ### Type-only props/emit declarations
 
-Props and emits can also be declared using pure-type syntax by passing a literal type argument to `useOptions`:
+Props and emits can also be declared using pure-type syntax by passing a literal type argument to `defineOptions`:
 
 ```ts
-const { props, emit } = useOptions<{
+const { props, emit } = defineOptions<{
   props: {
     foo: string
     bar?: number
@@ -215,7 +215,7 @@ const { props, emit } = useOptions<{
 }>()
 ```
 
-- `useOptions` can only use either runtime declaration OR type declartion. Using both at the same time will result in a compile error.
+- `defineOptions` can only use either runtime declaration OR type declartion. Using both at the same time will result in a compile error.
 
 - When using type declaration, equivalent runtime declaration is automatically generated from static analysis to remove the need of double declaration and still ensure correct runtime behavior.
 

From eb3dc12853c446a2fbbedf6ae3adeac72e583833 Mon Sep 17 00:00:00 2001
From: Evan You <yyx990803@gmail.com>
Date: Tue, 24 Nov 2020 15:47:07 -0500
Subject: [PATCH 06/20] edits: defineOptions -> defineProps + defineEmit +
 useContext

---
 active-rfcs/0000-script-setup.md | 167 ++++++++++++++++++++++++-------
 1 file changed, 133 insertions(+), 34 deletions(-)

diff --git a/active-rfcs/0000-script-setup.md b/active-rfcs/0000-script-setup.md
index 54ca4a23..48404fc3 100644
--- a/active-rfcs/0000-script-setup.md
+++ b/active-rfcs/0000-script-setup.md
@@ -62,6 +62,22 @@ Introduce a new script type in Single File Components: `<script setup>`, which e
 **Note:** the SFC compiler also extracts binding metadata from `<script setup>` and use it during template compilation. This is why the template can use `Foo` as a component here even though it's returned from `setup()` instead of registered via `components` option.
 
 </details>
+<p></p>
+
+**Declaring Props and Emits**
+
+```html
+<script setup>
+  import { defineProps, defineEmit } from 'vue'
+
+  // expects props options
+  const props = defineProps({
+    foo: String,
+  })
+  // expects emits options
+  const emit = defineEmits(['update', 'delete'])
+</script>
+```
 
 # Motivation
 
@@ -89,12 +105,11 @@ Any top-level bindings (both variables and imports) declared inside `<script set
 
 ```html
 <script setup>
-  import Foo from './Foo.vue'
   const msg = 'Hello!'
 </script>
 
 <template>
-  <Foo>{{ msg }}</Foo>
+  <div>{{ msg }}</div>
 </template>
 ```
 
@@ -103,14 +118,11 @@ Any top-level bindings (both variables and imports) declared inside `<script set
 
 ```html
 <script>
-  import Foo from './Foo.vue'
-
   export default {
     setup() {
       const msg = 'Hello!'
 
       return {
-        Foo,
         msg,
       }
     },
@@ -118,15 +130,88 @@ Any top-level bindings (both variables and imports) declared inside `<script set
 </script>
 
 <template>
-  <Foo>{{ msg }}</Foo>
+  <div>{{ msg }}</div>
+</template>
+```
+
+</details>
+<p></p>
+
+### Exposing Components and Directives
+
+Values in the scope of `<script setup>` can also be used directly as custom component tag names, similar to how it works in JSX:
+
+```html
+<script setup>
+  import Foo from './Foo.vue'
+</script>
+
+<template>
+  <Foo />
+</template>
+```
+
+<details>
+<summary>Compiled Output</summary>
+
+```html
+<script>
+  import Foo from './Foo.vue'
+
+  export default {
+    setup() {
+      return {
+        Foo,
+      }
+    },
+  }
+</script>
+
+<template>
+  <Foo />
 </template>
 ```
 
-**Note:** The SFC compiler also extracts binding metadata from `<script setup>` and use it during template compilation. Therefore in the template, `Foo` can be used as a component even though it's returned from `setup()` instead of registered via `components` option.
+**Note**: in this case the template compiler has the binding information to generate code that directly use `Foo` from setup bindings instead of dynamically resolving it.
 
 </details>
 <p></p>
 
+Directives work in a similar fashion, except that a directive named `v-my-dir` will map to a setup scope variable named `vMyDir`:
+
+```html
+<script setup>
+  import vMyDir from './directives/my-dir'
+</script>
+
+<template>
+  <div v-my-dir />
+</template>
+```
+
+<details>
+<summary>Compiled Output</summary>
+
+```html
+<script>
+  import vMyDir from './directives/my-dir'
+
+  export default {
+    setup() {
+      return {
+        vMyDir,
+      }
+    },
+  }
+</script>
+
+<template>
+  <div v-my-dir />
+</template>
+```
+
+</details>
+
 ### Scoping mental model
 
 Some users may be concerned that it is no longer clear what variables are exposed to the template vs. those that are not. However, it can be argued that there is no practical benefits in being able to tell this.
@@ -156,66 +241,67 @@ In a Vue component, everything exposed to the template is implicitly exposed on
 
 `<script setup>` as proposed in this RFC, if following current behavior, will be vastly over-exposing on the imperative public interface, therefore a component using `<script setup>` will be **closed by default**. That is to say, its public imperative interface will be an empty object unless bindings are explicitly exposed. How to explicitly expose imperative public interface will be finalized in https://github.com/vuejs/rfcs/pull/210.
 
-### Declaring options and setup context
+### Declaring props, emits and setup context
 
-In order to declare options like `props` and `emits`, and also receive arguments that are passed to the `setup()` function, we can use the newly introduced `defineOptions` API:
+In order to declare options like `props` and `emits`, and also access the setup context object, we can use the `defineProps`, `defineEmit` and `useContext` APIs:
 
 ```html
 <script setup>
-  import { defineOptions } from 'vue'
+  import { defineProps, defineEmit, useContext } from 'vue'
 
-  const { props, emit, slots, attrs } = defineOptions({
-    props: {
-      foo: String,
-    },
-    emits: ['change', 'delete'],
+  const props = defineProps({
+    foo: String,
   })
-
+  const emit = defineEmit(['change', 'delete'])
+  const { slots, attrs } = useContext()
   // setup code
 </script>
 ```
 
-The return value of `defineOptions` is the setup context (2nd argument passed to `setup()`). Note that in current core API, the setup context does not expose `props` - in order to align the concepts, we are updating the setup context to expose `props` as well.
-
-**Compiled output**
+<details>
+<summary>Compiled output</summary>
 
 ```html
 <script>
+  import { useContext } from 'vue'
+
   export default {
     props: {
       foo: String,
     },
     emits: ['change', 'delete'],
-    setup(_, { props, emit, slots, attrs }) {
+    setup(props, { emit }) {
+      const { slots, attrs } = useContext()
       // setup code
     },
   }
 </script>
 ```
 
-**Additional notes:**
+</details>
+
+- `defineProps` and `defineEmit` provides proper type inference based on the options passed.
 
-- `defineOptions` provides type inference similar to `defineComponent`.
+- `defineProps` and `defineEmit` are **compiler hints**. They are compiled away when `<script setup>` is processed. The actual runtime implementations are no-ops and should never be called. Doing so will result in a runtime warning.
 
-- `defineOptions` is a **compiler hint function**: it is compiled away when `<script setup>` is processed. The actual runtime implementation is a no-op and should never be called. Doing so will result in a runtime warning.
+- The options passed to `defineProps` and `defineEmit` will be hoisted out of setup into module scope. Therefore, the options cannot reference local variables declared in setup scope. Doing so will result in a compile error. However, it _can_ reference imported bindings since they are in the module scope as well.
 
-- The options passed to `defineOptions` will be hoisted out of setup into module scope. Therefore, the options cannot reference local variables declared in setup scope. Doing so will result in a compile error. However, it _can_ reference imported bindings since they are in the module scope as well.
+- `useContext()` is an actual runtime API that simply returns the same context object passed to `setup()`.
 
 ### Type-only props/emit declarations
 
-Props and emits can also be declared using pure-type syntax by passing a literal type argument to `defineOptions`:
+Props and emits can also be declared using pure-type syntax by passing a literal type argument to `defineProps` or `defineEmit`:
 
 ```ts
-const { props, emit } = defineOptions<{
-  props: {
-    foo: string
-    bar?: number
-  }
-  emit: (e: 'update' | 'delete', id: number) => void
+const props = defineProps<{
+  foo: string
+  bar?: number
 }>()
+
+const emit = defineEmit<(e: 'update' | 'delete', id: number) => void>()
 ```
 
-- `defineOptions` can only use either runtime declaration OR type declartion. Using both at the same time will result in a compile error.
+- `defineProps` or `defineEmit` can only use either runtime declaration OR type declaration. Using both at the same time will result in a compile error.
 
 - When using type declaration, equivalent runtime declaration is automatically generated from static analysis to remove the need of double declaration and still ensure correct runtime behavior.
 
@@ -254,6 +340,10 @@ Top level `await` can be used inside `<script setup>`. The resulting `setup()` f
 
 </details>
 
+<p></p>
+
+Relevant: https://github.com/vuejs/rfcs/issues/234
+
 ## Usage alongside normal `<script>`
 
 There are some cases where the code must be executed in the module scope, for example:
@@ -299,6 +389,14 @@ export default {
 
 </details>
 
+## `inheritAttrs`
+
+The `<script setup>` syntax provides the ability to express equivalent functionality of all existing Options API options except `inheritAttrs`. To declare `inheritAttrs: false` when using `<script setup>`, simply add `inherit-attrs="false"` to the `<template>` tag:
+
+```html
+<template inherit-attrs="false"> ... </template>
+```
+
 ## 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.
@@ -325,7 +423,8 @@ This feature is opt-in. Existing SFC usage is unaffected.
 
 # Unresolved questions
 
-This RFC depends on https://github.com/vuejs/rfcs/pull/210 being resolved first.
+- Providing props default values when using type-only props declaration.
+- This RFC depends on https://github.com/vuejs/rfcs/pull/210.
 
 # Appendix
 
@@ -418,7 +517,7 @@ The `bindings` object will be:
 
 ```js
 {
-  foo: 'setup',
+  foo: 'setup-const',
   bar: 'props'
 }
 ```

From 6478fe08bba262d09ac40aed9fa2abdeff875879 Mon Sep 17 00:00:00 2001
From: Evan You <yyx990803@gmail.com>
Date: Tue, 24 Nov 2020 19:00:28 -0500
Subject: [PATCH 07/20] edit: directive name mapping

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

diff --git a/active-rfcs/0000-script-setup.md b/active-rfcs/0000-script-setup.md
index 48404fc3..b30bc3cd 100644
--- a/active-rfcs/0000-script-setup.md
+++ b/active-rfcs/0000-script-setup.md
@@ -144,10 +144,13 @@ Values in the scope of `<script setup>` can also be used directly as custom comp
 ```html
 <script setup>
   import Foo from './Foo.vue'
+  import MyComponent from './MyComponent.vue'
 </script>
 
 <template>
   <Foo />
+  <!-- kebab-case also works -->
+  <my-component />
 </template>
 ```
 
@@ -157,11 +160,13 @@ Values in the scope of `<script setup>` can also be used directly as custom comp
 ```html
 <script>
   import Foo from './Foo.vue'
+  import MyComponent from './MyComponent.vue'
 
   export default {
     setup() {
       return {
         Foo,
+        MyComponent,
       }
     },
   }
@@ -169,6 +174,7 @@ Values in the scope of `<script setup>` can also be used directly as custom comp
 
 <template>
   <Foo />
+  <my-component />
 </template>
 ```
 
@@ -177,15 +183,15 @@ Values in the scope of `<script setup>` can also be used directly as custom comp
 </details>
 <p></p>
 
-Directives work in a similar fashion, except that a directive named `v-my-dir` will map to a setup scope variable named `vMyDir`:
+Directives work in a similar fashion - a directive named `v-my-dir` will map to a setup scope variable named `myDir`:
 
 ```html
 <script setup>
-  import vMyDir from './directives/my-dir'
+  import { directive as clickOutside } from 'v-click-outside'
 </script>
 
 <template>
-  <div v-my-dir />
+  <div v-click-outside />
 </template>
 ```
 
@@ -194,22 +200,21 @@ Directives work in a similar fashion, except that a directive named `v-my-dir` w
 
 ```html
 <script>
-  import vMyDir from './directives/my-dir'
+  import { directive as clickOutside } from 'v-click-outside'
 
   export default {
     setup() {
       return {
-        vMyDir,
+        clickOutside,
       }
     },
   }
 </script>
 
 <template>
-  <div v-my-dir />
+  <div v-click-outside />
 </template>
 ```
-
 </details>
 
 ### Scoping mental model

From 3ec3531ff87467626bd3e4a04b440ecd01da42fd Mon Sep 17 00:00:00 2001
From: Evan You <yyx990803@gmail.com>
Date: Mon, 21 Jun 2021 11:13:49 -0400
Subject: [PATCH 08/20] defineEmit -> defineEmits

---
 active-rfcs/0000-script-setup.md | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/active-rfcs/0000-script-setup.md b/active-rfcs/0000-script-setup.md
index b30bc3cd..ea00103d 100644
--- a/active-rfcs/0000-script-setup.md
+++ b/active-rfcs/0000-script-setup.md
@@ -68,7 +68,7 @@ Introduce a new script type in Single File Components: `<script setup>`, which e
 
 ```html
 <script setup>
-  import { defineProps, defineEmit } from 'vue'
+  import { defineProps, defineEmits } from 'vue'
 
   // expects props options
   const props = defineProps({
@@ -248,16 +248,16 @@ In a Vue component, everything exposed to the template is implicitly exposed on
 
 ### Declaring props, emits and setup context
 
-In order to declare options like `props` and `emits`, and also access the setup context object, we can use the `defineProps`, `defineEmit` and `useContext` APIs:
+In order to declare options like `props` and `emits`, and also access the setup context object, we can use the `defineProps`, `defineEmits` and `useContext` APIs:
 
 ```html
 <script setup>
-  import { defineProps, defineEmit, useContext } from 'vue'
+  import { defineProps, defineEmits, useContext } from 'vue'
 
   const props = defineProps({
     foo: String,
   })
-  const emit = defineEmit(['change', 'delete'])
+  const emit = defineEmits(['change', 'delete'])
   const { slots, attrs } = useContext()
   // setup code
 </script>
@@ -285,17 +285,17 @@ In order to declare options like `props` and `emits`, and also access the setup
 
 </details>
 
-- `defineProps` and `defineEmit` provides proper type inference based on the options passed.
+- `defineProps` and `defineEmits` provides proper type inference based on the options passed.
 
-- `defineProps` and `defineEmit` are **compiler hints**. They are compiled away when `<script setup>` is processed. The actual runtime implementations are no-ops and should never be called. Doing so will result in a runtime warning.
+- `defineProps` and `defineEmits` are **compiler hints**. They are compiled away when `<script setup>` is processed. The actual runtime implementations are no-ops and should never be called. Doing so will result in a runtime warning.
 
-- The options passed to `defineProps` and `defineEmit` will be hoisted out of setup into module scope. Therefore, the options cannot reference local variables declared in setup scope. Doing so will result in a compile error. However, it _can_ reference imported bindings since they are in the module scope as well.
+- The options passed to `defineProps` and `defineEmits` will be hoisted out of setup into module scope. Therefore, the options cannot reference local variables declared in setup scope. Doing so will result in a compile error. However, it _can_ reference imported bindings since they are in the module scope as well.
 
 - `useContext()` is an actual runtime API that simply returns the same context object passed to `setup()`.
 
 ### Type-only props/emit declarations
 
-Props and emits can also be declared using pure-type syntax by passing a literal type argument to `defineProps` or `defineEmit`:
+Props and emits can also be declared using pure-type syntax by passing a literal type argument to `defineProps` or `defineEmits`:
 
 ```ts
 const props = defineProps<{
@@ -303,10 +303,10 @@ const props = defineProps<{
   bar?: number
 }>()
 
-const emit = defineEmit<(e: 'update' | 'delete', id: number) => void>()
+const emit = defineEmits<(e: 'update' | 'delete', id: number) => void>()
 ```
 
-- `defineProps` or `defineEmit` can only use either runtime declaration OR type declaration. Using both at the same time will result in a compile error.
+- `defineProps` or `defineEmits` can only use either runtime declaration OR type declaration. Using both at the same time will result in a compile error.
 
 - When using type declaration, equivalent runtime declaration is automatically generated from static analysis to remove the need of double declaration and still ensure correct runtime behavior.
 

From 4c4cb247baf3748cd56def3bcd9f83e18d3009c2 Mon Sep 17 00:00:00 2001
From: Evan You <yyx990803@gmail.com>
Date: Mon, 21 Jun 2021 11:41:02 -0400
Subject: [PATCH 09/20] clarify auto name inference, clarify additional options
 declaration, remove inherit-attrs

---
 active-rfcs/0000-script-setup.md | 48 +++++++++++++++++++++++++++-----
 1 file changed, 41 insertions(+), 7 deletions(-)

diff --git a/active-rfcs/0000-script-setup.md b/active-rfcs/0000-script-setup.md
index ea00103d..f3432e22 100644
--- a/active-rfcs/0000-script-setup.md
+++ b/active-rfcs/0000-script-setup.md
@@ -215,6 +215,7 @@ Directives work in a similar fashion - a directive named `v-my-dir` will map to
   <div v-click-outside />
 </template>
 ```
+
 </details>
 
 ### Scoping mental model
@@ -298,10 +299,11 @@ In order to declare options like `props` and `emits`, and also access the setup
 Props and emits can also be declared using pure-type syntax by passing a literal type argument to `defineProps` or `defineEmits`:
 
 ```ts
-const props = defineProps<{
-  foo: string
-  bar?: number
-}>()
+const props =
+  defineProps<{
+    foo: string
+    bar?: number
+  }>()
 
 const emit = defineEmits<(e: 'update' | 'delete', id: number) => void>()
 ```
@@ -394,12 +396,44 @@ export default {
 
 </details>
 
-## `inheritAttrs`
+## Automatic `name` Inference
+
+Vue 3 SFCs automatically infers the component's name from the component's **filename** in the following cases:
+
+- Dev warning formatting
+- DevTools inspection
+- Recursive self-reference. E.g. a file named `FooBar.vue` can refer to itself as `<FooBar/>` in its template.
+
+  This has lower priority than explicity registered/imported components. If you have a named import that conflicts with the component's inferred name, you can alias it:
+
+  ```js
+  import { FooBar as FooBarChild } from './components'
+  ```
+
+In most cases, explicit `name` declaration is not needed. The only cases where you do need it is when you need the `name` for `<keep-alive>` inclusion / exclusion or direct inspection of the component's options.
+
+## Declaring Additional Options
+
+The `<script setup>` syntax provides the ability to express equivalent functionality of most existing Options API options except for a few:
 
-The `<script setup>` syntax provides the ability to express equivalent functionality of all existing Options API options except `inheritAttrs`. To declare `inheritAttrs: false` when using `<script setup>`, simply add `inherit-attrs="false"` to the `<template>` tag:
+- `name`
+- `inheritAttrs`
+- Custom options needed by plugins or libraries
+
+If you need to delcare these options, use a separate normal `<script>` block with `export default`:
 
 ```html
-<template inherit-attrs="false"> ... </template>
+<script>
+export default {
+  name: 'CustomName',
+  inheritAttrs: false,
+  customOptions: {}
+}
+</script>
+
+<script setup>
+  // script setup logic
+</script>
 ```
 
 ## Usage restrictions

From 4cf81b009b8538fbbf815899e15d3eeee748e557 Mon Sep 17 00:00:00 2001
From: Evan You <yyx990803@gmail.com>
Date: Mon, 21 Jun 2021 11:46:59 -0400
Subject: [PATCH 10/20] useContext() -> useSlots() + useAttrs()

---
 active-rfcs/0000-script-setup.md | 36 ++++++++++++++++++++------------
 1 file changed, 23 insertions(+), 13 deletions(-)

diff --git a/active-rfcs/0000-script-setup.md b/active-rfcs/0000-script-setup.md
index f3432e22..c6100758 100644
--- a/active-rfcs/0000-script-setup.md
+++ b/active-rfcs/0000-script-setup.md
@@ -247,19 +247,19 @@ In a Vue component, everything exposed to the template is implicitly exposed on
 
 `<script setup>` as proposed in this RFC, if following current behavior, will be vastly over-exposing on the imperative public interface, therefore a component using `<script setup>` will be **closed by default**. That is to say, its public imperative interface will be an empty object unless bindings are explicitly exposed. How to explicitly expose imperative public interface will be finalized in https://github.com/vuejs/rfcs/pull/210.
 
-### Declaring props, emits and setup context
+### Declaring `props` and `emits`
 
-In order to declare options like `props` and `emits`, and also access the setup context object, we can use the `defineProps`, `defineEmits` and `useContext` APIs:
+To declare options like `props` and `emits` with full type inference support, we can use the `defineProps` and `defineEmits` APIs:
 
 ```html
 <script setup>
-  import { defineProps, defineEmits, useContext } from 'vue'
+  import { defineProps, defineEmits } from 'vue'
 
   const props = defineProps({
     foo: String,
   })
+
   const emit = defineEmits(['change', 'delete'])
-  const { slots, attrs } = useContext()
   // setup code
 </script>
 ```
@@ -269,15 +269,12 @@ In order to declare options like `props` and `emits`, and also access the setup
 
 ```html
 <script>
-  import { useContext } from 'vue'
-
   export default {
     props: {
       foo: String,
     },
     emits: ['change', 'delete'],
     setup(props, { emit }) {
-      const { slots, attrs } = useContext()
       // setup code
     },
   }
@@ -292,7 +289,20 @@ In order to declare options like `props` and `emits`, and also access the setup
 
 - The options passed to `defineProps` and `defineEmits` will be hoisted out of setup into module scope. Therefore, the options cannot reference local variables declared in setup scope. Doing so will result in a compile error. However, it _can_ reference imported bindings since they are in the module scope as well.
 
-- `useContext()` is an actual runtime API that simply returns the same context object passed to `setup()`.
+### Using `slots` and `attrs`
+
+Usage of `slots` and `attrs` inside `<script setup>` should be relatively rare, since you can access them directly as `$slots` and `$attrs` in the template. In the rare case where you do need them, use the `useSlots` and `useAttrs` helpers respectively:
+
+```html
+<script setup>
+  import { useSlots, useAttrs } from 'vue'
+
+  const slots = useSlots()
+  const attrs = useAttrs()
+</script>
+```
+
+`useSlots` and `useAttrs` are actual runtime functions that return the equivalent of `setupContext.slots` and `setupContext.attrs`. They can be used in normal composition API functions as well.
 
 ### Type-only props/emit declarations
 
@@ -424,11 +434,11 @@ If you need to delcare these options, use a separate normal `<script>` block wit
 
 ```html
 <script>
-export default {
-  name: 'CustomName',
-  inheritAttrs: false,
-  customOptions: {}
-}
+  export default {
+    name: 'CustomName',
+    inheritAttrs: false,
+    customOptions: {},
+  }
 </script>
 
 <script setup>

From fb4427303fa63983c8f8cb1450d907afa0ff4032 Mon Sep 17 00:00:00 2001
From: Evan You <yyx990803@gmail.com>
Date: Mon, 28 Jun 2021 14:56:38 -0400
Subject: [PATCH 11/20] document defineEmits type literal + call signature
 syntax

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

diff --git a/active-rfcs/0000-script-setup.md b/active-rfcs/0000-script-setup.md
index c6100758..bf8f9d08 100644
--- a/active-rfcs/0000-script-setup.md
+++ b/active-rfcs/0000-script-setup.md
@@ -309,13 +309,15 @@ Usage of `slots` and `attrs` inside `<script setup>` should be relatively rare,
 Props and emits can also be declared using pure-type syntax by passing a literal type argument to `defineProps` or `defineEmits`:
 
 ```ts
-const props =
-  defineProps<{
-    foo: string
-    bar?: number
-  }>()
-
-const emit = defineEmits<(e: 'update' | 'delete', id: number) => void>()
+const props = defineProps<{
+  foo: string
+  bar?: number
+}>()
+
+const emit = defineEmits<{
+  (e: 'change', id: number): void
+  (e: 'update', value: string): void
+}>()
 ```
 
 - `defineProps` or `defineEmits` can only use either runtime declaration OR type declaration. Using both at the same time will result in a compile error.
@@ -328,7 +330,12 @@ const emit = defineEmits<(e: 'update' | 'delete', id: number) => void>()
 
   - The emitted code is still TypeScript with valid typing, which can be further processed by other tools.
 
-- As of now, the type declaration argument must be a literal type to ensure correct static analysis. This can be improved in the future.
+- As of now, the type declaration argument must be one of the following to ensure correct static analysis:
+
+  - A type literal
+  - A reference to a an interface or a type literal in the same file
+
+  Currently complex types and type imports from other files are not supported. It is theoretically possible to support type imports in the future.
 
 ### Top level await
 

From 3d195365f34d0a12f9ca87289e6bb0427ddfe861 Mon Sep 17 00:00:00 2001
From: Evan You <yyx990803@gmail.com>
Date: Mon, 28 Jun 2021 15:00:34 -0400
Subject: [PATCH 12/20] add faqs

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

diff --git a/active-rfcs/0000-script-setup.md b/active-rfcs/0000-script-setup.md
index bf8f9d08..8d52bfbf 100644
--- a/active-rfcs/0000-script-setup.md
+++ b/active-rfcs/0000-script-setup.md
@@ -484,6 +484,50 @@ This feature is opt-in. Existing SFC usage is unaffected.
 
 # Appendix
 
+
+## FAQs
+
+### How to tell which properties are exposed to the template?
+
+You don't. An important mental model shift when using `<script setup>` is to think of the `<template>` as **a function inside the setup scope** instead of "bound to a `this` context":
+
+```js
+function setup() {
+  const a = 1
+  const b = 2
+
+  return function template() {
+    // has access to `b` but doesn't necessarily uses it
+    return `<div>${a}</div>`
+  }
+}
+```
+
+A function inside another function naturally has access to everything declared within the parent function's scope. The parent scope is a closure and it doesn't leak the variables to anything but the inner function. This is also why `<script setup>` components are closed by default: it won't expose anything on its ref instance unless explicitly declared.
+
+### How to declare options like `name`?
+
+See [Declaring Additional Options](#declaring-additional-options) and [Automatic Name Inference](#automatic-name-inference).
+
+### How to use imported components as dynamic components?
+
+Within `<script setup>`, imported components are **variables** instead of a registered asset looked up using string keys. So when using imported components as dynamic components, instead of `<component is="Foo">`, it should be `<component :is="Foo"/>`. You can also use these variables in expressions, e.g. `<component :is="ok ? Foo : Bar"/>`
+
+### How to use render functions w/ script setup?
+
+You can't. But you don't need to use SFC if you are using render functions in the first place.
+
+```js
+const comp = defineComponent({
+  setup() {
+    const foo = ref(1)
+    // return render function w/ JSX
+    return () => <div>{foo.value}</div>
+  }
+})
+```
+
+
 ## Transform API
 
 The `@vue/compiler-sfc` package exposes the `compileScript` method for processing `<script setup>`:

From 3f4378fd2e995cb4ed2dbb1d84a45d1e61ea730f Mon Sep 17 00:00:00 2001
From: Evan You <yyx990803@gmail.com>
Date: Mon, 28 Jun 2021 15:04:28 -0400
Subject: [PATCH 13/20] update tooling status

---
 active-rfcs/0000-script-setup.md | 10 +++-------
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/active-rfcs/0000-script-setup.md b/active-rfcs/0000-script-setup.md
index 8d52bfbf..4e2e8f12 100644
--- a/active-rfcs/0000-script-setup.md
+++ b/active-rfcs/0000-script-setup.md
@@ -463,15 +463,11 @@ Due to the difference in module execution semantics, code inside `<script setup>
 
 This new scoping model will require tooling adjustments in two aspects:
 
-1. ESLint rules like `no-unused-vars`. We will need a replacement rule in `eslint-plugin-vue` that takes both the `<script setup>` and `<template>` expressions into account.
+1. IDEs will need to provide dedicated handling for this new `<script setup>` model in order to provide template expression type checking / props validation, etc.
 
-2. Vetur and other IDEs will need to provide dedicated handling for this new `<script setup>` model in order to provide template expression type checking / props validation, etc.
+    As of now, [Volar](https://github.com/johnsoncodehk/volar) already provides full support for this RFC in VSCode, including all TypeScript related features. Its internals are also implemented as a landuage server that can theoretically be used in other IDEs.
 
-One thing to note is that `<script setup>` syntax should make it easier for tools to analyze available bindings to the template compared to current Options API inside `<script setup>` (especially with mixins). A potential approach is transforming the entire SFC into a TSX file (similar to [svelte2tsx](https://github.com/sveltejs/language-tools/tree/master/packages/svelte2tsx)) for type-checking and refactoring support only.
-
-# Alternatives
-
-https://github.com/vuejs/rfcs/pull/182 (current `<script setup>` implementation)
+2. ESLint rules like `no-unused-vars`. We will need a replacement rule in `eslint-plugin-vue` that takes both the `<script setup>` and `<template>` expressions into account.
 
 # Adoption strategy
 

From 36dda7e71818fafc3d3b2586e89619619807409e Mon Sep 17 00:00:00 2001
From: Evan You <yyx990803@gmail.com>
Date: Mon, 28 Jun 2021 15:15:03 -0400
Subject: [PATCH 14/20] Clarify `defineProps`/`defineEmits` as compiler macros,
 remove need to import them. Also specofy usage of `defineExpose`.

---
 active-rfcs/0000-script-setup.md | 40 +++++++++++++++++++++-----------
 1 file changed, 27 insertions(+), 13 deletions(-)

diff --git a/active-rfcs/0000-script-setup.md b/active-rfcs/0000-script-setup.md
index 4e2e8f12..77772c3b 100644
--- a/active-rfcs/0000-script-setup.md
+++ b/active-rfcs/0000-script-setup.md
@@ -68,8 +68,6 @@ Introduce a new script type in Single File Components: `<script setup>`, which e
 
 ```html
 <script setup>
-  import { defineProps, defineEmits } from 'vue'
-
   // expects props options
   const props = defineProps({
     foo: String,
@@ -222,7 +220,7 @@ Directives work in a similar fashion - a directive named `v-my-dir` will map to
 
 Some users may be concerned that it is no longer clear what variables are exposed to the template vs. those that are not. However, it can be argued that there is no practical benefits in being able to tell this.
 
-In the past we have always considered the `<script>` and `<template>` parts of an SFC to be separate parts that need an explicit protocol to be "connected". It does feel different to have this separation blurred. However, if we switch the scoping mental model to view an SFC as returning a render function from the `setup()` closure instead:
+In the past we have always considered the `<script>` and `<template>` parts of an SFC to be separate parts that need an explicit `this` context to be "connected". It does feel different to have this separation blurred. However, if we switch the scoping mental model to view an SFC as returning a render function from the `setup()` closure instead:
 
 ```js
 function setup() {
@@ -241,20 +239,12 @@ In fact, we have also introduced an [inline template](#inline-template-mode) opt
 
 This does require different handling when linting for unused variables, but SFCs already require the usage of `eslint-plugin-vue` which can be made to adapt to this new scoping model.
 
-### Closed by default
-
-In a Vue component, everything exposed to the template is implicitly exposed on the component instance, which can be retrieved by a parent component via template refs. That is to say, up to this point the **template render context** and the **imperative public interface** of a component is one and the same. We have found this to be problematic because the two use cases do not always align perfectly. In fact, most of the time we are over-exposing on the public interface front. This is why we are discussing an explicit way to define a component's imperative public interface in https://github.com/vuejs/rfcs/pull/210.
-
-`<script setup>` as proposed in this RFC, if following current behavior, will be vastly over-exposing on the imperative public interface, therefore a component using `<script setup>` will be **closed by default**. That is to say, its public imperative interface will be an empty object unless bindings are explicitly exposed. How to explicitly expose imperative public interface will be finalized in https://github.com/vuejs/rfcs/pull/210.
-
 ### Declaring `props` and `emits`
 
-To declare options like `props` and `emits` with full type inference support, we can use the `defineProps` and `defineEmits` APIs:
+To declare options like `props` and `emits` with full type inference support, we can use the `defineProps` and `defineEmits` APIs, which are automatically avaialbe inside `<script setup>`:
 
 ```html
 <script setup>
-  import { defineProps, defineEmits } from 'vue'
-
   const props = defineProps({
     foo: String,
   })
@@ -285,7 +275,7 @@ To declare options like `props` and `emits` with full type inference support, we
 
 - `defineProps` and `defineEmits` provides proper type inference based on the options passed.
 
-- `defineProps` and `defineEmits` are **compiler hints**. They are compiled away when `<script setup>` is processed. The actual runtime implementations are no-ops and should never be called. Doing so will result in a runtime warning.
+- `defineProps` and `defineEmits` are **compiler macros** only usable inside `<script setup>`. They do not need to be imported, and are compiled away when `<script setup>` is processed.
 
 - The options passed to `defineProps` and `defineEmits` will be hoisted out of setup into module scope. Therefore, the options cannot reference local variables declared in setup scope. Doing so will result in a compile error. However, it _can_ reference imported bindings since they are in the module scope as well.
 
@@ -368,6 +358,30 @@ Top level `await` can be used inside `<script setup>`. The resulting `setup()` f
 
 Relevant: https://github.com/vuejs/rfcs/issues/234
 
+### Exposing component's public interface
+
+In a traditional Vue component, everything exposed to the template is implicitly exposed on the component instance, which can be retrieved by a parent component via template refs. That is to say, up to this point the **template render context** and the **imperative public interface** of a component is one and the same. We have found this to be problematic because the two use cases do not always align perfectly. In fact, most of the time we are over-exposing on the public interface front. This is why we are discussing an explicit way to define a component's imperative public interface in the [Expose RFC](https://github.com/vuejs/rfcs/pull/210).
+
+With `<script setup>` the template has access to the declared variables because it is compiled into a function that is returned from the `setup()` function scope. This means all the variables declared are in fact never returned: they are contained inside the `setup()` closure. As a result, a component using `<script setup>` will be **closed by default**. That is to say, its public imperative interface will be an empty object unless bindings are explicitly exposed.
+
+To explicitly expose properties in a `<script setup>` component, use the `defineExpose` compiler macro:
+
+```html
+<script setup>
+const a = 1
+const b = ref(2)
+
+defineExpose({
+  a,
+  b
+})
+</script>
+```
+
+When a parent gets an instance of this component via template refs, the retrieved instance will be of the shape `{ a: number, b: number }` (refs are automatically unwrapped just like on normal instances).
+
+This will be compiled into the runtime equivalent as proposed in the [Expose RFC](https://github.com/vuejs/rfcs/pull/210).
+
 ## Usage alongside normal `<script>`
 
 There are some cases where the code must be executed in the module scope, for example:

From 843d01c850f19a347d86539b13eba3da3722e2fe Mon Sep 17 00:00:00 2001
From: Evan You <yyx990803@gmail.com>
Date: Mon, 28 Jun 2021 15:19:18 -0400
Subject: [PATCH 15/20] withDefaults

---
 active-rfcs/0000-script-setup.md | 17 ++++++++++++++++-
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/active-rfcs/0000-script-setup.md b/active-rfcs/0000-script-setup.md
index 77772c3b..dd015f70 100644
--- a/active-rfcs/0000-script-setup.md
+++ b/active-rfcs/0000-script-setup.md
@@ -327,6 +327,22 @@ const emit = defineEmits<{
 
   Currently complex types and type imports from other files are not supported. It is theoretically possible to support type imports in the future.
 
+### Default props values when using type declaration
+
+One drawback of the type-only `defineProps` declaration is that it doesn't have a way to provide default values for the props. To resolve this problem, a `withDefaults` compiler macro is also provided:
+
+```ts
+interface Props {
+  msg?: string
+}
+
+const props = withDefaults(defineProps<Props>(), {
+  msg: 'hello'
+})
+```
+
+This will be compiled to equivalent runtime props `default` options. In addition, the `withDefaults` helper provides type checks for the default values, and ensures the returned `props` type has the optional flags removed for properties that do have default values declared.
+
 ### Top level await
 
 Top level `await` can be used inside `<script setup>`. The resulting `setup()` function will be made `async`:
@@ -489,7 +505,6 @@ This feature is opt-in. Existing SFC usage is unaffected.
 
 # Unresolved questions
 
-- Providing props default values when using type-only props declaration.
 - This RFC depends on https://github.com/vuejs/rfcs/pull/210.
 
 # Appendix

From cec8596f4bfc59f6feafcae13bb89dadcd0a35f0 Mon Sep 17 00:00:00 2001
From: Evan You <yyx990803@gmail.com>
Date: Mon, 28 Jun 2021 15:20:09 -0400
Subject: [PATCH 16/20] remove unresolved question

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

diff --git a/active-rfcs/0000-script-setup.md b/active-rfcs/0000-script-setup.md
index dd015f70..51063643 100644
--- a/active-rfcs/0000-script-setup.md
+++ b/active-rfcs/0000-script-setup.md
@@ -505,11 +505,10 @@ This feature is opt-in. Existing SFC usage is unaffected.
 
 # Unresolved questions
 
-- This RFC depends on https://github.com/vuejs/rfcs/pull/210.
+N/A
 
 # Appendix
 
-
 ## FAQs
 
 ### How to tell which properties are exposed to the template?

From ea683b8c1d5cd572dbb0cb5e756345b887289654 Mon Sep 17 00:00:00 2001
From: Evan You <yyx990803@gmail.com>
Date: Mon, 28 Jun 2021 18:10:44 -0400
Subject: [PATCH 17/20] update code examples to use inlined compile output

---
 active-rfcs/0000-script-setup.md | 288 ++++++++++++-------------------
 1 file changed, 110 insertions(+), 178 deletions(-)

diff --git a/active-rfcs/0000-script-setup.md b/active-rfcs/0000-script-setup.md
index 51063643..e14ce000 100644
--- a/active-rfcs/0000-script-setup.md
+++ b/active-rfcs/0000-script-setup.md
@@ -33,30 +33,25 @@ Introduce a new script type in Single File Components: `<script setup>`, which e
 <details>
 <summary>Compiled Output</summary>
 
-```html
-<script setup>
-  import Foo from './Foo.vue'
-  import { ref } from 'vue'
+```js
+import Foo from './Foo.vue'
+import { ref } from 'vue'
 
-  export default {
-    setup() {
-      const count = ref(1)
-      const inc = () => {
-        count.value++
-      }
-
-      return {
-        Foo, // see note below
+export default {
+  setup() {
+    const count = ref(1)
+    const inc = () => {
+      count.value++
+    }
+
+    return function render() {
+      return h(Foo, {
         count,
-        inc,
-      }
-    },
+        onClick: inc
+      })
+    }
   }
-</script>
-
-<template>
-  <Foo :count="count" @click="inc" />
-</template>
+}
 ```
 
 **Note:** the SFC compiler also extracts binding metadata from `<script setup>` and use it during template compilation. This is why the template can use `Foo` as a component here even though it's returned from `setup()` instead of registered via `components` option.
@@ -99,7 +94,7 @@ To opt-in to the syntax, add the `setup` attribute to the `<script>` block:
 
 ### Top level bindings are exposed to template
 
-Any top-level bindings (both variables and imports) declared inside `<script setup>` are directly exposed to the template render context:
+When using `<script setup>`, the template is compiled into a render function that is inlined inside the setup function scope. This means any top-level bindings (both variables and imports) declared inside `<script setup>` are directly usable in the template:
 
 ```html
 <script setup>
@@ -111,31 +106,26 @@ Any top-level bindings (both variables and imports) declared inside `<script set
 </template>
 ```
 
-<details>
-<summary>Compiled Output</summary>
+**Compiled Output:**
 
-```html
-<script>
-  export default {
-    setup() {
-      const msg = 'Hello!'
+```js
+export default {
+  setup() {
+    const msg = 'Hello!'
 
-      return {
-        msg,
-      }
-    },
+    return function render() {
+      // has access to everything inside setup() scope
+      return h('div', msg)
+    }
   }
-</script>
-
-<template>
-  <div>{{ msg }}</div>
-</template>
+}
 ```
 
-</details>
-<p></p>
+It is important to notice the different template scoping mental model vs. Options API: when using Options API, the `<script>` and the template are connected via a "render context object". When we write code, we are always thinking about "what properties are exposed on the context". This naturally leads to concerns of "leaking too much private logic onto the context".
+
+When using `<script setup>`, however, the mental model is simply that of a function inside another function: the inner function has access to everything in the parent scope, and because the parent scope is closure, there is no "leak" to be concerned with.
 
-### Exposing Components and Directives
+### Using Components
 
 Values in the scope of `<script setup>` can also be used directly as custom component tag names, similar to how it works in JSX:
 
@@ -155,25 +145,20 @@ Values in the scope of `<script setup>` can also be used directly as custom comp
 <details>
 <summary>Compiled Output</summary>
 
-```html
-<script>
-  import Foo from './Foo.vue'
-  import MyComponent from './MyComponent.vue'
+```js
+import Foo from './Foo.vue'
+import MyComponent from './MyComponent.vue'
 
-  export default {
-    setup() {
-      return {
-        Foo,
-        MyComponent,
-      }
-    },
+export default {
+  setup() {
+    return function render() {
+      return [
+        h(Foo),
+        h(MyComponent)
+      ]
+    }
   }
-</script>
-
-<template>
-  <Foo />
-  <my-component />
-</template>
+}
 ```
 
 **Note**: in this case the template compiler has the binding information to generate code that directly use `Foo` from setup bindings instead of dynamically resolving it.
@@ -181,32 +166,50 @@ Values in the scope of `<script setup>` can also be used directly as custom comp
 </details>
 <p></p>
 
-Directives work in a similar fashion - a directive named `v-my-dir` will map to a setup scope variable named `myDir`:
+### Using Dynamic Components
+
+Since components are referenced as variables instead of registered under string keys, we should use dynamic `:is` binding when using dynamic components inside `<script setup>`:
 
 ```html
 <script setup>
-  import { directive as clickOutside } from 'v-click-outside'
+  import Foo from './Foo.vue'
+  import Bar from './Bar.vue'
 </script>
 
 <template>
-  <div v-click-outside />
+  <component :is="Foo" />
+  <component :is="someCondition ? Foo : Bar" />
 </template>
 ```
 
 <details>
 <summary>Compiled Output</summary>
 
-```html
-<script>
-  import { directive as clickOutside } from 'v-click-outside'
+```js
+import Foo from './Foo.vue'
+import Bar from './Bar.vue'
 
-  export default {
-    setup() {
-      return {
-        clickOutside,
-      }
-    },
+export default {
+  setup() {
+    return function render() {
+      return [
+        h(Foo),
+        h(someCondition ? Foo : Bar)
+      ]
+    }
   }
+}
+```
+
+</details>
+
+### Using Directives
+
+Directives work in a similar fashion - except that a directive named `v-my-dir` will map to a setup scope variable named `vMyDir`:
+
+```html
+<script setup>
+  import { directive as vClickOutside } from 'v-click-outside'
 </script>
 
 <template>
@@ -214,30 +217,26 @@ Directives work in a similar fashion - a directive named `v-my-dir` will map to
 </template>
 ```
 
-</details>
-
-### Scoping mental model
-
-Some users may be concerned that it is no longer clear what variables are exposed to the template vs. those that are not. However, it can be argued that there is no practical benefits in being able to tell this.
-
-In the past we have always considered the `<script>` and `<template>` parts of an SFC to be separate parts that need an explicit `this` context to be "connected". It does feel different to have this separation blurred. However, if we switch the scoping mental model to view an SFC as returning a render function from the `setup()` closure instead:
+<details>
+<summary>Compiled Output</summary>
 
 ```js
-function setup() {
-  let a = 1
-  let b = a + 1
-
-  // the returned function has access to everything inside setup()
-  // however it may or may not use all of them.
-  return () => {
-    return h('div', b)
+import { directive as vClickOutside } from 'v-click-outside'
+
+export default {
+  setup() {
+    return function render() {
+      return withDirectives(h('div'), [
+        [vClickOutside]
+      ])
+    }
   }
 }
 ```
 
-In fact, we have also introduced an [inline template](#inline-template-mode) option that will compile SFCs into this format. By inlining the generated render function inside `setup()` scope, we can directly access in scope variables without having to go through the render proxy. This can lead to decent performance gains.
+</details>
 
-This does require different handling when linting for unused variables, but SFCs already require the usage of `eslint-plugin-vue` which can be made to adapt to this new scoping model.
+The reason for requiring the `v` prefix is because it is quite likely for a globally registered directive (e.g. `v-focus`) to clash with a locally declared variable of the same name. The `v` prefix makes the intention of using a variable as a directive more explicit and reduces unintended "shadowing".
 
 ### Declaring `props` and `emits`
 
@@ -257,18 +256,16 @@ To declare options like `props` and `emits` with full type inference support, we
 <details>
 <summary>Compiled output</summary>
 
-```html
-<script>
-  export default {
-    props: {
-      foo: String,
-    },
-    emits: ['change', 'delete'],
-    setup(props, { emit }) {
-      // setup code
-    },
+```js
+export default {
+  props: {
+    foo: String,
+  },
+  emits: ['change', 'delete'],
+  setup(props, { emit }) {
+    // setup code
   }
-</script>
+}
 ```
 
 </details>
@@ -509,48 +506,7 @@ N/A
 
 # Appendix
 
-## FAQs
-
-### How to tell which properties are exposed to the template?
-
-You don't. An important mental model shift when using `<script setup>` is to think of the `<template>` as **a function inside the setup scope** instead of "bound to a `this` context":
-
-```js
-function setup() {
-  const a = 1
-  const b = 2
-
-  return function template() {
-    // has access to `b` but doesn't necessarily uses it
-    return `<div>${a}</div>`
-  }
-}
-```
-
-A function inside another function naturally has access to everything declared within the parent function's scope. The parent scope is a closure and it doesn't leak the variables to anything but the inner function. This is also why `<script setup>` components are closed by default: it won't expose anything on its ref instance unless explicitly declared.
-
-### How to declare options like `name`?
-
-See [Declaring Additional Options](#declaring-additional-options) and [Automatic Name Inference](#automatic-name-inference).
-
-### How to use imported components as dynamic components?
-
-Within `<script setup>`, imported components are **variables** instead of a registered asset looked up using string keys. So when using imported components as dynamic components, instead of `<component is="Foo">`, it should be `<component :is="Foo"/>`. You can also use these variables in expressions, e.g. `<component :is="ok ? Foo : Bar"/>`
-
-### How to use render functions w/ script setup?
-
-You can't. But you don't need to use SFC if you are using render functions in the first place.
-
-```js
-const comp = defineComponent({
-  setup() {
-    const foo = ref(1)
-    // return render function w/ JSX
-    return () => <div>{foo.value}</div>
-  }
-})
-```
-
+> The following sections are only for tooling authors that needs to support `<script setup>` in respective SFC tooling integrations.
 
 ## Transform API
 
@@ -570,64 +526,40 @@ if (descriptor.script || descriptor.scriptSetup) {
 
 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.
 
-## Inline Template Mode
+## Inline vs. Non-Inline Mode
 
-Inline template mode can be enabled via the `inlineTemplate` option:
+During development, `<script setup>` still compiles to returned object instead of inlined render function for two reasons:
 
-```js
-compileScript(descriptor, { inlineTemplate: true })
-```
-
-This will compile the SFC template as well and inline it inside the `setup()` function generated from `<script setup>`. Example:
-
-```html
-<script setup>
-  import { ref } from 'vue'
+1. Devtools inspection
+2. Template hot-reloading (HMR)
 
-  const count = ref(0)
+Inline template mode is only used in production and can be enabled via the `inlineTemplate` option:
 
-  function inc() {
-    count.value++
-  }
-</script>
-<template>
-  <button @click="inc">{{ count }}</button>
-</template>
+```js
+compileScript(descriptor, { inlineTemplate: true })
 ```
 
-**Compiled to:**
+In inline mode, some bindings (e.g. return values from `ref()` calls) need to be wrapped with `unref`:
 
 ```js
-import { ref, unref, createVNode, toDisplayString } from 'vue'
-
 export default {
   setup() {
-    const count = ref(0)
+    const msg = ref('hello')
 
-    function inc() {
-      count.value++
+    return function render() {
+      return h('div', unref(msg))
     }
-
-    return () => {
-      createVNode(
-        'div',
-        {
-          onClick: inc,
-        },
-        toDisplayString(unref(count))
-      )
-    }
-  },
+  }
 }
 ```
 
-Note some bindings need to be wrapped with `unref` - the compiler performs some heuristics to avoid this when possible. For example, function declarations and const declarations with literal initial values will not be wrapped with `unref`.
+The compiler performs some heuristics to avoid this when possible. For example, function declarations and const declarations with literal initial values will not be wrapped with `unref`.
 
 ## 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
+```html
 <script setup="props">
 export const foo = 1
 

From 975644dbbccc4e0490093d98c01249f76714545f Mon Sep 17 00:00:00 2001
From: Evan You <yyx990803@gmail.com>
Date: Mon, 28 Jun 2021 19:06:36 -0400
Subject: [PATCH 18/20] discuss type declaration import limitations

---
 active-rfcs/0000-script-setup.md | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/active-rfcs/0000-script-setup.md b/active-rfcs/0000-script-setup.md
index e14ce000..951b6070 100644
--- a/active-rfcs/0000-script-setup.md
+++ b/active-rfcs/0000-script-setup.md
@@ -502,7 +502,11 @@ This feature is opt-in. Existing SFC usage is unaffected.
 
 # Unresolved questions
 
-N/A
+- Type-only props/emits declarations currently do not support using externally imported types. This is useful when reusing base props type definitions across multiple components.
+
+  The type inference already works as expected in Volar's IDE support, the limitation is purely in that `@vue/compiler-sfc` needs to know the props keys in order to generate the correct equivalent runtime declarations.
+
+  This is technically possible if we implement the logic to follow along type imports, read, and parse the import source. However, this is more of an implementation scope problem and does not fundamentally affect how the RFC design behaves.
 
 # Appendix
 

From 4734bb687c8e76fddc47252b2c1b7d590319f306 Mon Sep 17 00:00:00 2001
From: Evan You <yyx990803@gmail.com>
Date: Tue, 29 Jun 2021 14:24:09 -0400
Subject: [PATCH 19/20] add details on async/await context preservation

---
 active-rfcs/0000-script-setup.md | 28 ++++++++++++++--------------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/active-rfcs/0000-script-setup.md b/active-rfcs/0000-script-setup.md
index 951b6070..ee64dbc9 100644
--- a/active-rfcs/0000-script-setup.md
+++ b/active-rfcs/0000-script-setup.md
@@ -350,24 +350,24 @@ Top level `await` can be used inside `<script setup>`. The resulting `setup()` f
 </script>
 ```
 
-<details>
-<summary>Compiled Output</summary>
+In addition, the awaited expression will be automatically wrapped with a `withAsyncContext` helper. The helper saves and restores the current instance context so that the current instance context is preserved even after the `await` statement:
 
-```html
-<script>
-  export default {
-    async setup() {
-      const post = await fetch(`/api/post/1`).then((r) => r.json())
+```js
+import { withAsyncContext } from 'vue'
 
-      return { post }
-    },
-  }
-</script>
-```
+export default {
+  async setup() {
+    const post = await withAsyncContext(
+      fetch(`/api/post/1`).then((r) => r.json())
+    )
 
-</details>
+    // current instance context preserved
+    // e.g. onMounted() will still work.
 
-<p></p>
+    return { post }
+  }
+}
+```
 
 Relevant: https://github.com/vuejs/rfcs/issues/234
 

From 3478b0be65bb80e5d0eeb8fc54357e2445a84824 Mon Sep 17 00:00:00 2001
From: Evan You <yyx990803@gmail.com>
Date: Thu, 1 Jul 2021 19:36:19 -0400
Subject: [PATCH 20/20] adjust rfc number

---
 active-rfcs/{0000-script-setup.md => 0038-script-setup.md} | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename active-rfcs/{0000-script-setup.md => 0038-script-setup.md} (100%)

diff --git a/active-rfcs/0000-script-setup.md b/active-rfcs/0038-script-setup.md
similarity index 100%
rename from active-rfcs/0000-script-setup.md
rename to active-rfcs/0038-script-setup.md