[Core Team RFC] Reactive Props Destructure

[yyx990803]

• Start Date: 2023-04-28
• Reference Issues: Reactivity Transform
• Implementation PR: N/A

Summary

Introduce a compile-time transform that makes destructured bindings from defineProps reactive.

This was part of the Reactivity Transform proposal and now split into a separate proposal of its own.

Basic example

<script setup>
import { watchEffect } from 'vue'

const { count } = defineProps(['count'])

watchEffect(() => {
  // referencing a destructured binding in tracking contexts
  // registers it as a dependency.
  // this will log every time the count prop changes from parent
  console.log(count)
})
</script>

<template>{{ foo }}</template>

With types (works exactly the same):

const { count } = defineProps<{ count: 0 }>()

Motivation

1. Succinct and native-like syntax for default values and local alias. Big DX improvement over withDefaults().

2. Previously, you can implicitly use declared props in <template>, e.g. with {{ foo }}, but in <script> using it as props.foo. With destructured props the usage becomes consistent.

Detailed design

Compilation Rules

The compilation logic is straightforward - the above example is compiled like the following:

Input

const { count } = defineProps(['count'])

watchEffect(() => {
  console.log(count)
})

Output

const __props = defineProps(['count'])

watchEffect(() => {
  console.log(__props.count)
})

Default Values

Users can leverage the native destructure default value syntax to declare default values for props:

const {
  n = 123,
  str = 'hello',
  obj = {}
} = defineProps(['n', 'str', 'obj'])

Also note that when declaring default value for non-primitive objects, it’s no longer necessary to use a factory function.

Local Renaming

Similarly, destructure with renaming is also supported:

const { n: localNumber = 123 } = defineProps(['n'])

Watch Guard

The compiler will error if a destructured prop is passed to the watch() API:

import { watch } from 'vue'

const { foo } = defineProps(['foo'])

watch(foo, () => {})
//    ^ compiler error, suggests () => foo

Drawbacks

Note: this feature has been implemented and tested as part of Reactivity Transform for quite some time, so we are keeping the motivation and design details short. We want to focus on whether this should be landed as a stable feature in this RFC, so we are trying to be exhaustive about potential drawbacks.

Cannot be passed directly to Composables

Users who are new to this feature could be mistakenly passing a destructured prop into a function and expect it to retain reactivity:

const { foo } = defineProps(['foo'])

useFeature(foo)

This isn't particularly about destructured props though: we have the same issue with the props object. You can just pass props.foo into a composable and expect it to stay reactive, so this isn't really a new problem.

Previously users have to come up with various patterns in order to pass props as refs:

const props = defineProps(['foo'])

// toRef
useComposable(toRef(props, 'foo'))

// computed
useComposable(computed(() => props.foo))

// toRefs
const { foo } = toRefs(props)
useComposable(foo)

With the toRef() enhancement and toValue() introduced in #7997, I hope we can consolidate the pattern to:

// with props object
const props = defineProps(['foo'])
useComposable(() => props.foo)

// with destructure
const { foo } = defineProps(['foo'])
useComposable(() => foo)

Not Obvious that it's a Prop

Some users have expressed that they prefer seeing props.foo which clearly indicates that it is a prop.

In small components, we are usually very aware of the props we expect. But in large components, it could be helpful to be able to instantly tell if something is a prop or just a normal variable.

However, with IDE support, one can always jump to definition to see whether something is a prop. So while it may affect readability to some extent, it does not fundamentally affect maintainability.

Interestingly, the same issue had always been present in Options API: everything is grabbed off of this, and very few users complained about it. There were some users who opted to go with this.$props.foo in order to differentiate props from local bindings, but this seems very uncommon, despite even weaker IDE support for Options API.

Potential Confusion for Beginners

Similar to Reactivity Transform, this feature introduces the concept of "compiler-magic-powered reactive binding". It requires the user to understand how reactivity tracking works to understand why this works, and is an exception to the "dot access means tracking" mental model.

This is probably the biggest reservation that we currently have about this feature. But we'd like to provide some counter arguments in favor of shipping it:

1. Props is a component-only concept, and reactive props only ever exist inside SFCs. Unlike Reactivity Transform, the boundary here is very clear. The magic never leaks into normal JS/TS code or composables.

2. We already have a lot of "compiler magic" in place, and users have managed to internalize them. For example, ref unwrapping in templates is conceptually almost identical to reactive props.

   The key here is whether the compiler magic incurs long term mental overhead. If it can be internalized and becomes muscle memory, then the DX gain will likely be worth it.

3. Composition API already requires understanding how reactivity tracking works to be used effectively. We can further reduce the chance of confusion by improving the intro parts of docs for Composition API - specifically, explain reactivity tracking earlier rather than leaving it in the advanced section.

Alternatives

• definePropsRefs

  Essentially sugar for toRefs(props), which allows destructuring props as refs. However, this does not improve the DX when declaring default values.

Adoption strategy

This is implemented and shipped as an experimental feature in 3.3 beta and requires explicit opt-in.

Vite

// vite.config.js
export default {
  plugins: [
    vue({
      script: {
        propsDestructure: true
      }
    })
  ]
}

vue-cli

Requires vue-loader@^17.1.1

// vue.config.js
module.exports = {
  chainWebpack: (config) => {
    config.module
      .rule('vue')
      .use('vue-loader')
      .tap((options) => {
        return {
          ...options,
          reactivityTransform: true
        }
      })
  }
}

[martinszeltins]

Not sure what others think or what the best practice is but I prefer not to destructure props on purpose so that I would know if I am dealing with a regular ref or a prop and it also makes it easier to distinguish and have separate variables where I can have name and props.name

<template>
  This is a name prop: {{ props.name }}
  This is a local variable: {{ name }}
</template>

<script setup>
  const props = defineProps(['name'])

  const name = ref('')
</script>

[yyx990803]

I think it's bad practice to have a prop and a local variable with the same name. It's theoretically possible, but why?

Also note this feature is entirely opt-in - you can 100% stick to props object if you want to.

[martinszeltins]

That means I need to pass an initial prop to my component like <MyComponent :initial-name="name" /> and in my component I might have a local name variable. But calling the prop initial-something is very strange and not very semantic.

[hworld]

I know this is late, but the proposal above specifies that it works with local renames:

const { n: localNumber = 123 } = defineProps(['n'])

So if you wanted to still use the destructure syntax instead of a props object, you can rename it locally in the component const { name: nameProp } = defineProps(['name']) and then the API for you component doesn't need to change.

[jods4]

Does the compiler support a code pattern that enables destructuring a few properties and keeping a props variable in scope?

There's no TS example but I assume everything works the same with the inclusion of a type parameter?

const { n } = defineProps<{ n: number }>()

Is parameters validation during dev still a thing?
How would that TS example look if we want to validate that only positive n are bound?

[jods4]

Can you think of a practical case where you need the entire props object and destructured props in the <script> section at the same time?

I have practical cases for that, although they're surely not very common.

For example, I built a components library for projects at work.
It contains a collection of input components for different types (text, lookup, dates, numbers, etc.).
There is a common set of props that are handled by a composable function, such as input label, placeholder, validation, hints, data-bound field, etc. -- and then there are props that are specific to the input component, such as the number of decimal places for a numeric input.

With this RFC, I imagine these components may look something like:

const { decimals, ...props } = defineProps();

const baseModel = useBaseInput(props); // Shared code that handles placeholders, labels, validation, etc.

// Code to handle specific options such as decimals.

I just made up the ...props way to grab the full props. It's enticing syntax although the semantics are slightly off, as it contains decimals but its apparent type does not.

Maybe those edge-cases are better left to const props = defineProps()...

3.3 DX is massively improved. The ability to import prop types from different files will greatly help this example as well, as I might do something like:

import type { BaseInputProps } from "./base-input"

const props = defineProps<{ decimals: number, ...BaseInputProps }>()

[Mohamadhassan98]

Not sure about the relation to this RFC or the pattern and/or performance issues. But this lines of code do what you want (With help of other reactivity transform helper, the $)

const props = defineProps<{ count: number }>();
const { count } = $(props);
watchEffect(() => {
  // will be called on each change, i.e. count is reactive
  console.log(count);
});

[jods4]

@Mohamadhassan98 The reactivity transformed was abandonned.

[gokhantaskan]

I want to understand if my implementation is wrong. I've tried the following code:

<script setup lang="ts">
...

const { type = "primary", ...props } = defineProps<ButtonProps>();
//                        ^^^ It's not a proxy object anymore, and breaks `v-bind`
</script>

<template>
  <Button
    :type="type"
    v-bind="props"
  >
  ...
  </Button>
</template>

So I needed to implement the following:

<script setup lang="ts">
...
const { type = "primary", ...props } = defineProps<ButtonProps>();
const _props = toRef(props);

// v-bind="_props" now works
</script>
...

What is the best way to achieve similar code with this syntax?

[MaxMonteil]

Maybe having the button specific props in their own object:

<script setup lang="ts">
type ButtonProps = {
  type?: 'primary' | 'secondary'
  props: {
    size: 'md' | 'lg'
    outline: boolean
  }
}

const { type = "primary", props } = defineProps<ButtonProps>();
</script>

<template>
  <Button
    :type="type"
    v-bind="props"
  >
  ...
  </Button>
</template>

You might also have the <Button /> in the template be a slot for the parent to directly pass in the button only props where they're already reactive.

Or even a computed property that regroups all the destructured properties into an object for the Button's v-bind.

Depends on your use case.

[fanckush]

if i were to hover over foo in the example below, what type would the IDE show me?

const { foo } = defineProps(['foo'])

useFeature(foo)

[Rolanddoda]

That looks awesome but I don't like the fact that we need to use a Getter when passing the prop to a composable in order to retain reactivity.

I think many of us do:

const props = defineProps({...})

const { foo } = toRefs(props)
useFeature(foo)

Now this code starting from 3.3 would be considered legacy/needs-improvements and the new syntax would be:

const { foo } = defineProps({...})

useFeature(() => foo)

---

Some things doesn't look right to me:

1. Since defineProps returns reactive destructed bindings, I would expect foo to work like a ref but instead, it is a magic variable that doesn't need .value but it is reactive

2. Using () => foo looks like a pattern many users won't like. I think it complicates things

I believe that this instead of improving the current DX, complicates things and make it more confusing for users with this non-ref reactive variable and the "thunking" pattern.

I would personally vote for defineProps with destructuring to act like toRefs(props) and each destructed binding to be a ref that's read only:

const { foo } = defineProps(...)

foo.value = 'new value' // ❌ should error
useFeature(foo) // ✅ works
watch(foo, handler) // ✅

[loilo]

I agree with your reservations, but if I understand this RFC correctly, the main advantage of destructuring here is the easy declaration of default values.

And this would be technically possible to do with your suggestion using a compilation step, but I think it would be highly irritating to users:

const { foo = 'default' } = defineProps<...>()

// `foo` is now a ref instead of the string value we literally just assigned to it

[h-sigma]

I agree. Having moved to exclusively using script setup SFCs and individual ref's (as opposed to reactive), adding magically reactive prop variables would be too confusing. Having the destructured values simply be a ref would be much more straightforward.

As for the default value thing pointed out by @loilo , I'd say the value -> ref conversion in the default part is perhaps much easier to believe as a developer considering that the anomaly is right next to a macro, as opposed to the magically reactive props that are spread throughout the component file.

[fleabitten232]

And this would be technically possible to do with your suggestion using a compilation step, but I think it would be highly irritating to users

Is the objection here that it's a magic transformation? So the 'correct', non-magical way to declare the default would be:

const { foo = ref('default') } = defineProps<...>()

That feels awkward and error-prone, even if it's more correct.

Personally, if I'm getting refs back from defineProps, I will also want the defaults to be refs 100% of the time. I don't want to have to write special cases to check if foo was set by an actual prop or by a fallback mechanism.

[loilo]

To your points, @fleabitten232:

Personally, if I'm getting refs back from defineProps, I will also want the defaults to be refs 100% of the time. I don't want to have to write special cases to check if foo was set by an actual prop or by a fallback mechanism.

Absolutely! Sorry if I have not been clear enough about that.

The { someProp = ref(...) } way of defining defaults would only make sense in a world where we'd get an object of refs when defining props (through something like definePropsRefs).

Is the objection here that it's a magic transformation?

Basically yes. More precisely, it's the kind of magic transformation that I'm objecting against.

We already have magic in our Single File Component scripts through macros like defineProps. However, their magic is very well encapsulated — it's indistinguishable from just using a hypothetical global defineProps function.

Reactive props would be quite the opposite: They distort JavaScript semantics throughout a whole <script> block. So the issue I'm objecting against is that a perfectly regular and quite common way of writing JavaScript code would work entirely differently than expected.

Using a simplified (!) code sample:
When I read const { foo = "bar" } = {}, I'd always expect foo to be "bar" — it literally is an immutable assignment. I'd neither expect it to change its value to any other string, nor would I expect it to become a ref with the value "bar" instead.

To clarify this: I'm not against this kind of magic in frameworks in general. Svelte also does various kinds of changes to the way JavaScript works. But it's fine because that's what you expect Svelte to do, warping JavaScript semantics in components (and in components only!) is literally "their thing".

The problem I'd be having with reactive props in Vue is that in the Vue world, this kind of magic would be such a blatant outlier.

Currently, Vue Single File Component <script> blocks are an environment where the JavaScript language works exactly the same as it does in a regular .js file. And while I'm not strictly against changing that (I haven't been supportive of the Reactivity Transform RFC, but I also had no hard feelings against it), I think that reactive props destructuring alone (!) is not enough of a benefit to justify sacrificing the assumption of "Single File Component <script> blocks are fully compatible JavaScript".

[so1ve]

// vue.config.js
module.exports = {
  chainWebpack: (config) => {
    config.module
      .rule('vue')
      .use('vue-loader')
      .tap((options) => {
        return {
          ...options,
          reactivityTransform: true // Shouldn't it be `propsDestructure: true` ?
        }
      })
  }
}

[sxzz]

It's a typo I guess

[linkurzweg]

// vite.config.js
export default {
  plugins: [
    vue({
      script: {
        propsDestructure: true
      }
    })
  ]
}

This causes a TypeScript error for me:

TS2322: Type '{ propsDestructure: true; defineModel: true; }' is not assignable to type 'Partial<Pick<SFCScriptCompileOptions, "babelParserPlugins">>'.   Object literal may only specify known properties, and 'propsDestructure' does not exist in type 'Partial<Pick<SFCScriptCompileOptions, "babelParserPlugins">>'.

[so1ve]

vitejs/vite-plugin-vue#173
Missing types but it works

[yyx990803]

Types fixed in 4.2.3

[loilo]

I highly appreciate the attempt to solve the problem of cumbersome assignment of default values, but I'd like to note that after using this feature with the Vue 3.3 alpha, I have strong reservations against having such a kind of "magic variable" in the <script setup> block.

I'm not new to Vue or TypeScript, I've been using both since 2016. But still, it was quite confusing to have reactive state that is neither a ref nor a property access. I think this is actually the main problem: that it's such a one-off. It does not align with what Vue usually does.

(Of course it does align with what Vue does in templates, but those are a DSL which therefore seems much less problematic to me.)

That said, I don't have a better solution to offer, I just wanted to spell out the doubts I have about this after some time of usage and reflection.

---

A less-than-optimal suggestion that crossed my mind: It could be allowed for definePropsRefs to declare default values like this:

const { count = ref(0) } = definePropsRefs<{ count: number }>()

I acknowledge this is still unwieldy, but it would match expectations with regards to Vue's current behavior, and IMO it's preferrable to withDefaults for small amounts of default values.

[KaelWD]

it does align with what Vue does in templates

I'd like to be able to turn it off in templates too tbh, just have everything work the same way everywhere. No magic reactive variables, no ref unwrapping, props only available under props.<>

[loilo]

I'd like to be able to turn it off in templates too

I've had that thought too, but that's definitely another topic. 😁

[nguyenvokim]

For me, when I look at the Drawbacks. It's trade off too much just for destructure a variable.

[linkurzweg]

I hope this will not be removed. I really like it and wouldn't consider the drawbacks that bad.

[Ragura]

We have been using this since it was available and have really come to appreciate the DX improvement. Together with toRef() and toValue() the usage in components is really comfortable as well. Yes, passing a getter can seem strange, but in bigger projects, if you were using props, you were already manually changing it to a ref or passing a computed anyway if you wanted to keep reactivity on the prop within the composable.

The DX gains in assigning default values are immense, but that was a given and I doubt anyone is against being able to drop withDefaults().

While I wasn't fully sold on Reactivity transform (because of the different syntax), this RFC seems to just fit in nicely with what SFC try to do for you as a developer. I encourage people to try this in a real project for a while and not have a knee-jerk reaction from a purely theoretical standpoint.

[unshame]

I'm surprised this doesn't come with a macro to turn these destructured props back into refs for passing into composables.

What's the composables that receive getters supposed to look like?

function useSomething(prop) {
    const propRef = toRef(prop);

    const something = computed(() => propRef.value.map(somethingElse))
}

or

function useSomething(prop) {
    const something = computed(() => toValue(prop).map(somethingElse))
}

?

Both seem more verbose and awkward than .value. This seems fine for libraries that want to have generic interfaces as much as possible, but for writing regular code it's not great. We already have Ref, Readonly, MaybeRef and Readonly, now we also get MaybeReadonlyRefOrGetter. And in projects without typescript this just adds another kind of argument to keep track of, or you have to toValue/toRef everything.

I feel like this proposal just pushes the awkwardness into composables, where the code is more complex already, instead of removing it. The introduction of getters just makes me feel like there's some regret in choosing .value instead of () to access reactive values.

I think I would prefer a combined definePropsWithDefaults that accepts the defaults as the argument and types as the generic. Trying this out made me realize that having props as a simple reactive object is totally fine.

[Rolanddoda]

As I have also mentioned here, I tend to agree with @unshame.

Doing props destructuring and getting a "magic variable" in return is a new pattern (if we can call it like this) that makes things confusing:

• Is this variable a ref? NO!
• Is this variable reactive? YES!
• Since is reactive can we watch it like a ref? NO!
• Can we pass it like a ref? NO!

Also, I don't buy on the getter function pattern because VueUse uses it internally! I guess we can say that it uses it because there isn't an alternative but also, VueUse does other complex things that normal users don't do/will rarely have to do.
So:

• Is this () => magic-variable pattern also new? YES!
• Do users use it extensively? I don't think so!
• Does it make things more confusing! YES!

---

On the other hand:

• Do we need props destructuring? YES!
• Do we want to get rid of defineProps+withDefaults(in the current form)? YES!
• Do we want to retain reactivity for destructured props? YES!
• Do we want to do that without a new pattern or magic variable? YES!

---

So weighting out these options, I think that it's clear (at least to me) that if we have a ref getting returned from destructuring props, we don't need these new patterns and overhead. e.g.

/* From VueMacros */

// ✅ won't lose reactivity with destructuring
const { foo, bar } = definePropsRefs<{
  foo: string
  bar: number
}>()

useFeature(foo, bar)

About the syntax we can argue but personally I would want to have refs returned from props destructuring so mentally I know that the variable I have is a ref and it's reactive.

[loilo]

So weighting out these options, I think that it's clear (at least to me) that if we have a ref getting returned from destructuring props, we don't need these new patterns and overhead. e.g.

Destructuring to refs has been possible since the availability of Composition API by doing toRefs(defineProps()).
I think the main advantage of this RFC is the possibility to assign default values in a more convenient way.

[unshame]

You have to do it in two lines, because defineProps is hoisted outside of the body of setup, hence why there's this macro https://vue-macros.sxzz.moe/macros/define-props-refs.html

[Rolanddoda]

@loilo maybe I wasn't that clear. I know the intention of the RFC and I am for this and support it but I think that if we get refs we won't need the magic variables and the "thunking pattern" useFeature(() => fooProp).

[MaxMonteil]

Maybe allowing wrapping defineProps with toRefs would be enough?
It matches what Pinia does with its storeToRefs.

Then default assignments would have to be refs due to types.

// clearly now, count must be used with .value
const { count = ref(0) } = toRefs(defineProps<{ count: number }>());
//       ^? Ref<number>

// Cannot assign type 'number' to type 'Ref<number>'
const { count = 0 } = toRefs(defineProps<{ count: number }>());

// without wrapping with toRefs, it just maintains the current behavior?
const { count = 0 } = defineProps(['count']);

Not sure how feasible it is to combine a macro with a runtime function though.

[rafaberaldo]

Instead of destructure I'd prefer the way vue-macros did with defineProp:

const count = defineProp<number>('count', { default: 1 })

Returning a ref (I think its possible?) so it can be passed to composables.

[WangZiChu199910252255]

Is there no need to add propsDestructure: true in version 3.3.4?

[lvjiaxuan]

You have misunderstood as I did. In <template>, it stays reactive as usual, while in <script>, it loses.

<script setup>
import { watchEffect } from 'vue'

const { msg = 'hello' } = defineProps(['msg'])

watchEffect(() => {
  // accessing `msg` in watchers and computed getters
  // tracks it as a dependency, just like accessing `props.msg`
  console.log(`msg is: ${msg}`)
})
</script>

<template>{{ msg }}</template>

[azabroflovski]

Keep both options, by default it will be reactive, but it would be possible to disable it (not at the level of the whole application, but of a specific component)

[yyx990803]

Why would you want to only disable it at component level?

From what I understand most users either want to use it or not. You definitely want your codebase to be consistent rather than using this feature only in some places.

[azabroflovski]

Why would you want to only disable it at component level?

I misspoke, although it probably sounds the same, I meant to say keep both syntaxes. I'm only in favor of adding props destructure so that it is enabled by default, but leaving the option to use the old syntax as well.

const props = defineProps<Props>()

I guess I'm not really thinking straight, but for some reason I remembered a case I had.

<script lang="ts" setup>
const { name } = defineProps<Props>()

// duplicate "name" 
const { name } = useComposable()
<script>

Solution:

<script lang="ts" setup>
// rename here
const { name: nameProp } = defineProps<Props>()

// or explicitly refer to the props variable (I'll know it's props).
const props = defineProps<Props>()

//  or rename here
const { name: nameYour } = useYourComposable()
<script>

imho, to reiterate my point: adding props destructure so that it is enabled by default, but leaving the option to use the old syntax as well

[yyx990803]

That's exactly how it's going to work.

[Inori-Lover]

const { a } = defineProps<{a: unknown}>()
const b = a
watchEffect(() => {
  console.log(a)
  console.log(b)
})

[sadeghbarati]

https://stackblitz.com/edit/vitejs-vite-hbsfkn

propsDestructure reactivity meant to be for props, not for everywhere

If you want to pass destructure prop to a composable you can use () => a prop getter function and toValue inside the composable to make it reactive

[yyx990803]

This is the equivalent of

const props = defineProps<{a: unknown}>()
const b = props.a
watchEffect(() => {
  console.log(props.a)
  console.log(b)
})

[Inori-Lover]

completely understand. The reason for writing this code is not because I think I have found a bug, but to remind you of a potential scenario that affects the maintainability of the code.

[sadeghbarati]

With the toRef() enhancement and toValue() introduced in vuejs/core#7997, I hope we can consolidate the pattern to:

https://stackblitz.com/edit/vitejs-vite-hkhny8

The only confusion here is what if I have to pass many props to a useComposable function like

Update: I meant to use object inside useComposable param but how when the props destructured?

const { foo, bar, baz, qwe, asd, zxc } = defineProps(['foo', 'bar', 'baz', 'qwe', 'asd', 'zxc'])
// or
const { foo, bar, baz, qwe, asd, zxc } = defineProps<{foo: any; bar: any; baz: any; qwe: any; asd: any; zxc: any;}>();


const wholePropObjectWhenItsDestructured = {
  foo,
  bar,
  baz,
  qwe,
  asd,
  zxc
}

const wholePropObjectWithReactive = reactive({
  foo: () => foo,
  bar: () => bar,
  baz: () => baz,
  qwe: () => qwe,
  asd: () => asd,
  zxc: () => zxc
})

// For example I want to keep props objects destructured
// I don't want to pass props object to composable
// How to pass the destructured props in a better way?
useComposable({
  foo: () => foo,
  bar: () => bar,
  baz: () => baz,
  qwe: () => qwe,
  asd: () => asd,
  zxc: () => zxc
})

[mosinve]

Looks like whole props object fit better here

[kiaking]

I think this has nothing to do with destructuring? How were you doing it without it? If your composable looks like that, then wouldn't it be like this anyway?

const props = defineProps(['foo', 'bar', 'baz', 'qwe', 'asd', 'zxc'])

useComposable(() => props.foo, () => props.bar,  () => props.baz, () => props.qwe, () => props.asd, () => props.zxc)

[mark980828]

这样做或许是不是会损失性能？如果本身是shallowReactive，这样做会有效果吗？对于新手体验上来说好一些，但是对于老手我相信大部分会觉得直观上会比较反人类，是不是有些过于黑魔法。觉得toRef和toRefs已经能很好的解决问题了，我觉得解构丧失响应性很符合正常js的心智模型，加上去有些不伦不类，有点当初$ref的感觉了，甚至有些方面不如$ref，团队协作$ref每个人可以选择用或者不用，这个直接作用全局就让一些人很难受。

[mark980828]

如果加的话建议新增函数类似'definePropsRef'来做这个功能，而不是全局开启或关闭，会让人感觉讨厌

[AndrewBogdanovTSS]

Or it might also be a good idea to have additional property on the script element that would indicate the scope of the feature

[yyx990803]

There's no perf lost because it has the exact same runtime cost compared to without using the sugar. In fact it would be more performant than toRefs(props).

[PerpetualWar]

So if I get this correct, destructured props will be reactive but not become refs?

That actually increases mental overhead imho.

Also passing getter function into composables feels inconsistent, to say the least.

[mark980828]

I agree, too much dark magic is not a good thing.

[yyx990803]

Again, we already addressed these concerns in the Drawbacks section of the RFC. Before commenting, please make sure to absorb the full context of prior discussions and argue against specific points - it would be much more constructive than just sharing a generic first-impression.

[PerpetualWar]

I thought I did. My point is: Can we stay in the existing paradigm of ref (signal) being the lowest reactive mechanism, rather than introducing some other mechanisms (magic vars), case or location specific as this proposal aims to do?

Now , I do understand that if they were to be refs, settings defaults is (a bit more) problematic.

But, I would still say, staying in that ref paradigm is better tradeoff than going down the route of magic vars.

I hope I'm a bit clearer now.

[johnsoncodehk]

I'm using defineModel instead of defineProps in personal projects wherever possible, I've found that this alleviates withDefaults DX issues and doesn't introduce mental overhead. This may serve as a ready-made alternative for people who don't like Reactive Props Destructure.

/**
 * // Compare with:
 * const {
 *  n = 123,
 *  str = 'hello',
 *  obj = {},
 *  foo
 * } = defineProps(['n', 'str', 'obj', 'foo'])
 * 
 * watch(() => foo, () => {});
 */
const n = defineModel('n');
const str = defineModel('str', { default: 'hello' });
const obj = defineModel('obj', { default: {} });
const foo = defineModel('foo');

// ✅ works
watch(foo, () => {});

[kiaking]

This is actually a very interesting idea. Maybe having defineProp macro to define props one by one might make sense 😅

[yyx990803]

defineProp has been discussed within the team and is indeed preferred by some, but it lacks the ability to reuse props definitions (either via interface extends when using type-based declaration or object spreads with runtime declaration). Same problem with defineModel.

e.g.

import { SharedProps } from './types'

interface Props extends SharedProps {
  // ...
}

defineProps<Props>()

[jods4]

@yyx990803 Because it doesn't cover every possible case doesn't mean it has no value.
Components with shared props can rely on defineProps but most components do not have shared props and would be well served with defineProp.

Also, wouldn't that work: const name = defineProp<SharedProps["name"]>()?

[Fuzzyma]

Since this feature needs compilation anyway, I am all for making destructured props refs and not magic variables.
In the template, refs are unboxed as well, so it actually would be more consistent overall without adding an inconsistency in the script section.

So this:

const { foo = 5 } = defineProps<{ foo?: number}>()

becomes

const $props = defineProps({ foo: { type: Number } })
const foo = toRef(() => $props.foo ?? 5)

Implementation (or compilation) details may vary.
I dont see, why destructuring with default cant be compiled to a ref instead of a magic var.

Doing this also reduced the work the compiler has to do overall because you are actually defining the ref as such. So no need to search for foo and replace it with $props.foo everywhere.

[Pentadome]

I think the problem with this is that typescript will think foo is a number instead of Ref<number>

[s3xysteak]

The feature makes the reactivity of vue more complex to me. Here is a example:

isReactive(data) // true
watch(data, () => { /* ... */ })

What will happen?

From our experience, it just work. Of course, a Reactive can be watch().

However, now there is a different ending. It could also throw a error if the complete code is:

const { data } = defineProps<{ data: Record<string, any> }>()

isReactive(data) // true
watch(data, () => { /* ... */ }) // ! oops!

The code is actually equal to watch(props.data, () => { /* ... */ }), which should be watch(() => props.data, () => { /* ... */ }) and cause the problem.

Although there is a error message from @vue/compiler-sfc clearly report how that happened, I still think that is so weird. It feels like the Destructure Props is a new reactive type which is different from ref and reactive.

I like @Fuzzyma 's idea. It feels like defineProps is a composable. I think most people are used to deconstructing the object returned by a composable and getting a ref, because of vueuse.

[simonmaass]

Just to clarify cause i am a but confused:
reactivity transform was completly dropped in 3.4 and props destructure is part of that... but in 3.5 the props destructure will be in core...

[skirtles-code]

Not exactly.

Reactivity transform was about working with refs, allowing the .value to be dropped. Early implementations didn't include any specific support for props.

Props destructuring was an idea that was introduced later.

The two ideas have many similarities and even shared some code internally, but they were distinct features. For the sake of simplicity they were often discussed together under the umbrella of 'reactivity transform', as most of the discussion of one also applied to the other. That included props destructuring being added to the RFC for reactivity transform.

When it was first announced that reactivity transform would be dropped, it was also announced that props destructuring would still be pursued, albeit in a slightly different form. That's what this RFC was for.

The props destructuring feature was hidden behind a flag throughout that period. It wasn't removed when reactivity transforms were removed. The change in 3.5 will be to enable it by default.

[Pentadome]

The fact that one variable can be completely different from another variable with exactly the same type seems wild to me.

Abusing typescript like this is a major mistake in my opinion.

This might be more convenient, but it will cause people to misunderstand how vue's reactivity works.

People are going to wonder why one variable is reactive and the other not when they are both not Refs.

Perhaps I'm overreacting but the benefit would be that we don't need to use:
-withDefaulfs
-toRefs

• sometimes not .value

These benefits seem tiny to me to be worth it.

Perhaps if the compiler would make everything implicitly reactive and not just props then at least that would be consistent, but this halfway approach will only bring confusion imo.

[yoshi-pi]

In vanilla JavaScript, when specifying default values, is it better to use destructuring or the traditional default property?

[Fuzzyma]

I would use the default property. In most cases you have to define the object anyway. So you might as well set the default there

[nmu-bouharri]

There is a small linting concern here, pardon me if it has been addressed. If I use this new API to set a default for a prop but don't use it in <script setup>, my TSConfig's noUnusedLocals rule flags an error in my IDE (PhpStorm). Is there a recommendation for dealing with this?

Edit: "hasn't" > "has"

[hdy1023]

<script setup lang="ts">
import { reactive, watch} from 'vue'
const { count } = defineProps({
  count:Number
})
watch(() => count, () => { 
  // is working
  console.log(11111)
})

const { count2 } = reactive({ count2:1 })
watch(() => count2, () => { 
  // is not working
  console.log(22222)
})
</script>

This SFC based magic compilation may lead to a deeper understanding reactivity of vue. Why can't 'reactive' be deconstructed? The story should be reflected in the doc for beginners.

[guaijie]

@yyx990803 个人对于库作者而言的印象是：库的作者非常优秀，但太轴了。很多开发者在实践中给出的建议很多并未被采纳。
当我升级 vue 至 3.5 以上时才发现 propsDestructure 这么一个糟糕的特性实现。这一特性的提出非常有意义，但实现的并不是想象的那回事。很多开发者只顾着使用，并未真正考虑可读性以及维护的成本。

ref 和 reactive 的使用已经在整个社区被热议：‘到底应该使用哪一个’。现在有多了一种看上去跟普通变量无二的响应式数据（虽然只是在最后被编译成 props.prop，而不是真正的新增了一种响应式数据结构）。但是这样真的好吗？

使用上已经让开发者犯难（不单单是 ref 和 reactive 两者的问题，还包括各种奇葩的修改响应式数据的方式），现在连区分响应式数据都困难了。

这是个人的建议， 如果有兴趣可以看看，算是班门弄斧了

[guaijie]

@yyx990803 我最近才开始使用，也是最近才发现这个 RFC , 但评论区已经出现这么多不同的声音。这个一致性问题应该是优先考虑的。这个最终结果就是破坏了一致性。还有就是为啥什么要关闭掉 discussion 而且限制发言。
使用 idea 提示和数据结构的不一致是两回事。