-
-
Notifications
You must be signed in to change notification settings - Fork 8.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(compiler-sfc): support using other prop as default value in props destructuring #12387
base: main
Are you sure you want to change the base?
Conversation
Size ReportBundles
Usages
|
@vue/compiler-core
@vue/compiler-ssr
@vue/compiler-dom
@vue/compiler-sfc
@vue/reactivity
@vue/runtime-core
@vue/runtime-dom
@vue/server-renderer
@vue/shared
vue
@vue/compat
commit: |
⏳ Triggered ecosystem CI: Open |
📝 Ran ecosystem CI: Open
|
Do you think a use case like this should be supported? const { items, start = 0, end = items.length } = defineProps<{
items: string[],
start?: number,
end?: number
}>() I'm also wondering about the impact of prop ordering. For example, this will work: const { a = 0, b = a } = defineProps<{
a?: number,
b?: number,
}>() But this (with const { a = 0, b = a } = defineProps<{
b?: number,
a?: number,
}>() In some ways this isn't a new problem, as the ordering has always mattered, but it's maybe less intuitive when the defaults are being applied via props destructuring. |
close #12386