feat(compiler-sfc): withDefaults supports the use of local variables

[zqran]

close: #8517

---

Usage:

<script setup lang="ts">
  import { ref } from 'vue'
  const defaultsObject = { name: "Evan You" }
  const props = withDefaults(defineProps<{name: string}>(), defaultsObject) // support local variable
</script>

[sxzz]

defaults should not be hoisted if it's used by other assignments.
https://deploy-preview-8592--vue-sfc-playground.netlify.app/#eNo9jkEKgzAQRa8yZKVYtGuJQqEH6AFmY+3YCjoJyaRdhNy9oVZ38/mPeT+qi7X1O5Bqlfajm62AJwkWloGfHSrxqHrk0bAXeNA0hEU8dBBhMqaFMyTkzyyv678qMjMz3ZyxXkdk2DgO650ccuqL8nT8KZH3s85YVSHrZluRnTkIrXYZhHICiD8npGzUzdGo9AW/zUYh

[zqran]

defaults should not be hoisted if it's used by other assignments.

Ok, with this situation in mind, I think there might be a few things to confirm:

1. defaults.foo = 'xxx' -> set property
2. defaults = {} -> set new value
3. defaults.xxx -> read property
4. someFunc(defaults) -> as parameter

[netlify]

❌ Deploy Preview for vue-sfc-playground failed.

Name	Link
🔨 Latest commit	1c14795
🔍 Latest deploy log	https://app.netlify.com/sites/vue-sfc-playground/deploys/648f060bee3fe400083fc8c1

[netlify]

❌ Deploy Preview for vue-next-template-explorer failed.

Name	Link
🔨 Latest commit	1c14795
🔍 Latest deploy log	https://app.netlify.com/sites/vue-next-template-explorer/deploys/648f060b0cb03c00088d4068

[sxzz]

@zqran No, if there's any reference not inside of withDefaults, then we can just hoist the variable (const only).

[zqran]

@sxzz

There are two different cases depending on the operation:

1. get
2. set

For the set case, as long as the value is modified it cannot be hoisted (explicitly).
For the get case, the following scenarios are possible:

• const (explicitly)

// hoist
const defaults = { baz: false }
const props = withDefaults(defineProps<{
  baz: boolean
}>(), defaults)

// If there are still the following operations:

// hoist
console.log(defaults)
someFunc(defaults)

• let (not explicitly)

// hoist
let defaults = { baz: false }
const props = withDefaults(defineProps<{
  baz: boolean
}>(), defaults)

// If there are still the following operations:

// need to confirm
console.log(defaults) // Special case? need to be excluded?
someFunc(defaults)

These different rules(scenarios that need to be confirmed above) may confuse users.

Therefore, since it is used as the default value, it is agreed that it cannot be modified. Then can we agree: If you want to use local variables as parameters of withDefault, you must use const declarations. This might be more explicit.

[sxzz]

Even tough it's const, we can still modify the property value of the object.

const obj = { a : 1 }
obj.a = 2

---

I think the better way for avoiding confusing is that local variables as parameters of withDefault should never used outside of withDefault.
For example we only support this case

const defaults = {}
withDefaults(defineProps(), defaults)

// defaults is never be used.
// console.log(defaults) // ❌
// defaults.add() // ❌
// someFunc(defaults) // ❌

[zqran]

It is worth mentioning that hoist will take effect when using reference:

// foo.ts
export const defaults = { baz: false }

import { defaults } from './foo'
const props = withDefaults(defineProps<{bar: boolean}>(), defaults)

// defaults is used:
console.log(defaults)
defaults.baz = true

If so, it may behave inconsistently with local variables.

[sxzz]

@zqran Cause exported variable is top level and always inited once, but in <script setup> (without this feature), it's inited every time. We must ensure there's no side effect if we hoist inner variable to the top level.

[zqran]

Thank you for your explanation, I will modify it according to the above content.

[sxzz]

Should hoist the first one statement instead of the second one
https://deploy-preview-8592--vue-sfc-playground.netlify.app/#eNqNjzELwjAQhf/KkaUtiKJjaQuCzroKt8Sa1kh7CcmlDiX/3Uh1cfK47b3vPd4s9taup6BEKSrfOm0ZvOJgYZDU1yjYo2iQ9GiNY5jBqQ4idM6MkCUsQ0JqDXmGm+pkGNifrg/VMtTJTHJUJaA4TpLgYsIOBUSkGQnS/Y1tFyz9glhnrE/Op+b74YPnKUeTOr+l6hvh2WnqITZ5sfopKpCqzTK4EfEFQEBcJQ==

[sxzz]

Suggested change

	> = {}
	> = Object.create(null)

[sxzz]

I think it's very hard to figure out which variable should be hoisted without scope stack (like we did in Reactivity Transform package). But if we introduce scope stack, it will greatly increase the complexity of the SFC compiler.

Maybe we need a complete refactor, I'm considering.

[zqran]

I think it's very hard to figure out which variable should be hoisted without scope stack (like we did in Reactivity Transform package). But if we introduce scope stack, it will greatly increase the complexity of the SFC compiler.

Maybe we need a complete refactor, I'm considering.

It's awesome! Looking forward to its progress.

[mosinve]

Hi, @zqran is this PR planning to merge? Looks like i need it very much)

[zqran]

Hi, @zqran is this PR planning to merge? Looks like i need it very much)

@mosinve
It may not work now. For specific reasons, please see the explanation of @sxzz above.

#8592 (comment)