[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>

[Corgis]

it‘s good !

[MaxMonteil]

Adding my 2 cents here, this feature is awesome! Already using it as the default in every place that accepts props.

Only confusion I had was with passing destructured props to composables as mentioned in the drawbacks section. This just requires keeping in mind what the compiled output is where it makes sense that reactivity would be lost.
If this is also included in the docs then it should be fine, along with references to the recent toRef and toValue so the community does consolidate on the proposed pattern.

10/10 DX

[leopiccionia]

This is the part that makes no sense to me. If you have to think about the compiled output a syntax is trying to abstract, then this abstraction has failed imho.

Just use foo where you'd use props.foo and () => foo where you'd use () => props.foo. It's very consistent and transparent, and easy to be taught IMHO.

If you want destructured props to behave like refs, be explicit and use toRefs(props).

[darrylnoakes]

Which is precisely the issue I have:

This introduces a different form of reactive variable that only applies for this, with new methods needed to use it.
And "if [we] want destructured props to behave like refs," we must "be explicit and use toRefs(props)." When would you actually want to use a whole new paradigm instead of plain old refs? Even if it is "very consistent and transparent, and easy to be taught", why do it all?
It is very easy and consistent for me to always wear my shirt inside out, but why do it all? What benefit is it compared to normal?

[clemdee]

@leopiccionia

I get your point, but the problem for me with that is that this is not as simple as "just" using this over that. I feel like this argument is trying to sweep the dust under the carpet, by simply disregarding the downsides that this proposal currently brings. Some major inconsistencies are being introduced here, and even if you can use a linter to prevent from shooting yourself in the foot, I think we can take the opportunity this proposal is still in RFC stage to try to improve it directly before it ships.

Also, as this reactive prop looks like a ref but does not behave like one, meaning that I now have to "just" use () => foo, now I have to differentiate it from my normal refs, because I'm not going to unecessarily wrap my refs inside lambda functions when passing them to composables. This also brings some mental overhead, and again, your linter can help you differentiate between the two, but you have to make the mistake first so that it corrects it, and you still cannot easily tell the two appart form one glance.

If you want destructured props to behave like refs, be explicit and use toRefs(props).

I'm a bit startled by this. Actually, this proposal was originally made to improve exactly what you are describing: having a better DX for keeping reactivity when destructuring props.
So the way I read this sentence is that if the current proposal didn't meet our needs (and indeed I'm still not convinced by it), our only choice would be to either keep using the low DX toRefs syntax we were unhappy with, or use the new system we are not fully satisfied with either. Which to me does not seem really helpful.

Just to be clear, I'm not advocating that the destructured props should specifically be refs, but that they should behave consistently and in coherence with what already exists in the language. If that requires that those destructured props are refs, then yes, I'd be in favor of refs, but I'd also be in favor of other alternatives that propose something consistent. In any case, I'm not looking for a "good enough" solution which could potentially brings more harm than good to the language, even if in the end that means staying where we are with the current DX.

[leopiccionia]

Props always behaved like this in Vue 3.
props is, and has always been, a reactive object, it's not a dictionary of refs.

If you want to handle a prop like a ref, you need to use toRef or toRefs, that exist since Composition API was firstly introduced.

props.foo behaves like any key from a reactive object, i.e.:

• it's reactive
• it's not a ref
• it's not a watch source

The only inconsistency this RFC introduces is that, differently from other reactive objects, props can be destructured, precisely only at the left side of an assignment expression where defineProps is called on the right side.

In my opinion, this change alone is a great DX improvement, and I've been using it in some projects.

[Semsemq]

💞

[Semsemq]

💖💖

[sadeghbarati]

What is the status of this rfc?

Reactivity Transform is dropped but this is a separate and good to have proposal without opt-in in @vitejs/plugin-vue
When it will come out of Experimental

---

Before propsDestructure:

const props = withDefaults(defineProps<Props>(), {
  variant: 'default',
  size: 'default',
})

const transferPropsToReactiveOne = computed(() => {
  // eslint-disable-next-line unused-imports/no-unused-vars
  const { variant, size, ...resetOfProps } = props
  return resetOfProps
})

After propsDestructure:

const { variant = 'default', size = 'default', ...resetOfProps } = defineProps<Props>()

[sadeghbarati]

bump!

[Semsemq]

👍
Thanks

[linkurzweg]

Would like an update on this as well!

[ArutaGerman]

Good feature, but we can't use with options and in v3.4.13 (we haven't Typescript):

const { sidebarId } = defineProps({
  sidebarId : {
    type: String,
    required: true,
  },
});

I mean: sidebarId is not reactive in this case.

RFC say: we can define props like defineProps(['sidebarId ']), but I want to define required option.
Do we have way for this?

[they-cloned-me]

Been using this ever since it was introduced—super great feature and I can’t wait for it to get stable.
withDefaults adds a bit of mental overhead (more stuff/name to remember), I wish we can kill it instead.

[Semsemq]

✨️👍

[an2n]

I've been using reactive props destructuring a lot and thought it was a stable part of Vue. I really hope it becomes a standard part of Vue soon.

[jnoordsij]

While aiming to ask some question about some other idea I had regarding prop reactivity and handling/detecting it, I ran into this RFC and must say I very much like the approach given that it makes things very much easier to work with avoiding common errors. However I do also have some fears about it obscuring a few things which I would like to raise (and maybe can be circumvented?).

From both the IDE typing and code, it seems non-obvious that some variable is a reactive prop, making it harder to see (and possibly also to detect in tooling like linters) that it is being used in a non-reactive manner; e.g. violating the no-setup-props-reactivity-loss rule; this might make it less obvious to which props a component is correctly responding in a reactive manner and for which props it just uses the "initial" value and nothing more after.

As to my original idea which led me to this, is the discussion on vuejs/eslint-plugin-vue#2259 regarding warnings about possibly reactivity loss on props. Looking at the discussion there and also the doc example about using a prop as initial value only, I was wondering if it would be fruitful to allow adding some metadata to mark a prop as "static" (naming up to debate); i.e. assume that it's value is only used on initial render and the component does not react to any further changes of the prop afterwards.

This would allow for any initial value prop to be marked as such and then IDE/tooling could be updated to:

• not consider any non-reactive usage of props as invalid, given we assume it to never change
• detect patterns where such props receive "dynamic" values from the parent component and mark those as invalid

Note: if this is too much unrelated to the original RFC and should be discussed elsewhere, let me know!

[bcdanieldickison]

I think the original RFC already describes the drawbacks well so I won't repeat them here, but I do want to share my opinion that these drawbacks are significant and I hope will be considered blockers for adopting this as standard.

Changing the semantics of how variables work in JS is going to cause serious confusion, especially for components with complex <script setup> logic. In a sense, this proposal adds syntactic sugar that makes simple components more convenient to write at the expense of making complex components more difficult to read, and I think that's the opposite of what Vue should be striving for.

[linkurzweg]

That's exactly what I was going to answer. If everybody had that attitude we'd still be on the options API. You're free to enforce any rules you want on your own codebase to prevent fragmentation.

[AndrewBogdanovTSS]

I would like to wholeheartedly support the above points. Ecosystem provides tools such as eslint to force a lot of specifics about which style of development your team is obligated to use in a specific project, it should never come as an accuse for limiting specific framework features.

[fleabitten232]

Edit: Oops. For some reason I thought this was a thread about a different RFC. Nothing I said was relevant here.

[linkurzweg]

@fleabitten232 This is just a small convenience feature imo and you're overdramatizing its impact.

Every article and example involving Vue would be forced to either become opinionated or outdated.

Oh come on, it's not like the current/old syntax won't work anymore, so the articles and examples would still work fine. It's not like half the articles on the web have to be rewritten. A small update to the Vue.js documentation is all that is needed, just like with defineModel, which was also an RFC before the current Vue version.

the decision is that it's not worth it here

Who has made that decision? You? This feature is still in RFC status.

[they-cloned-me]

Nahh... this feature is dope!

It is your responsibility to ensure your components don’t get too “complex”.
You don’t like? Use eslint rules to prevent usage in your codebase.

[yyx990803]

So far the sentiment from the feedback is that:

• A small minority of users are concerned with the semantics and do not want to use it at all.
• Users who have actually used it are liking it and have found no major issues.

So overall, I'm inclined to graduate this to a stable feature in 3.5, with the option to disable it for those who wish to prohibit its usage in their codebase. We will leave another week for soliciting last minute thoughts on this direction.

[lttr]

I like this. We are using this feature in 40 out of 120 components in our project right now. At the same time we are using const props = defineProps in a couple of cases where it fits better (usually longer and complex components). And no use of withDefaults, which is nice.

I also like the possibility to enforce consistency either with Vue itself or with eslint. At the same time it feels like ref vs reactive - while using ref most of the times, it is sometimes better to use reactive.

Does anyone have similar experiences?

[warmthsea]

const { count } = defineProps<{ count: 0 }>()
const { isFirstOpen = true } = defineProps<{ isFirstOpen?: boolean }>()

I like it. Both are used const {} = d.. const props = d..

[linkurzweg]

Very happy to read this! Finally :)

[volarname]

so when you have combination like this

const props = withDefaults(
  defineProps<{
    id: number
    count?: number
    name?: string
  }>(),
  {
    count: 0,
    name: 'unknown',
  }
)

and you want to use typescript definition + optional prop with default values + renaming, it will look like what, this?

const {
  id: propId,
  count: propCount = 0,
  name: propName = 'unknown' 
} = defineProps<{ id: IntegerId, count?: number, name?: string }>()

are the ? still needed to identify optional prop?

My opinion is that opt in/ opt out should be not a global thing, it should be possible per component, otherwise you will need to rewrite whole code instead of step-by-step. This issue is something you already did an you said you will not do it anymore.

my second question, will this work (client is from props desc)?

// eslint-disable-next-line vue/no-setup-props-reactivity-loss
const { t } = useComposable(client)

i dont care here about reactivity loss because client is constant or object
will this be eslint error only or compiler error? this is a different thing

[bodograumann]

Per-component opt-in should not be a problem, because iinm the old way of const props = defineProps<…>() would still work, even if you enable the feature globally.
There is only the edge case where you currently do non-reactive destructuring of props. That should be rare though, I would think.

[CernyMatej]

Yes you need to use ? to define the optional props.

[yyx990803]

This is fully compatible with all existing usage, so step-by-step rewrite is totally feasible.

[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

[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