destructure props

[veerman72]

To avoid error typescript ESLint: Getting a value from the props in root scope of <script setup> we need to destructure the props with toRefs()

[jessarcher]

Thanks for the PR, @veerman72.

Are there any real-world consequences with the current code? The full ESLint error I think we're talking about vue/no-setup-props-destructure:

Getting a value from the `props` in root scope of `<script setup>` will cause the value to lose reactivity  vue/no-setup-props-destructure

With or without this change, the values passed to the useForm won't have reactivity, which I'm pretty sure is what we want. It seems like this change just makes the linter happy at the expense of more complex code for developers.

Also, I'm not too sure how <script setup> gets compiled, but I don't think I understand how we're running afoul of the linting rule based on reading the docs linked above. Are there any resources you can provide?

If we were to use toRef/toRefs I'd imagine we'd want to make them readonly with the getter syntax (see the end of this section) to avoid the ability to mutate props.

[veerman72]

Thanks for your reply @jessarcher.

There are no real-world consequences with the current code and yes it is the ESLint error you mentioned.

If we want the values passed to the useForm not to be reactive we must not use toRef/toRefs but must use unref.

The code (only updated or added lines) then becomes:

import { unref } from 'vue'

const { token, email } = unref(props)

const form = useForm({
    token: token,
    email: email,
    password: '',
    password_confirmation: '',
})

Does it add complexity: yes.
Does it solve the ESLinting error: yes.
Does the (updated) code above solves the mentioned reactivity issue: yes

It is up to you whether you want this (updated) PR. I am not that an expert in software development as you are. I can only ask you why we use linters if we ignore the recommended settings subsets of core rules?

FYI I'm using the following ESLint extend properties: ['eslint:recommended', 'plugin:vue/vue3-recommended', '@vue/typescript/recommended', 'prettier']

[jessarcher]

Hey @veerman72,

I prefer the reduced complexity and overhead of unref, but as it just returns the exact instance we passed to it, it feels like a bit of a hack. I wouldn't mind so much if this was internal code, but I don't like having to add stuff like this to the code that we hand over to users.

My view is that the problem this rule is trying to protect us from is not a problem in this case. I see a lot of value in linters and this rule, but this case seems more like a false positive.

It's also worth noting this quote from the Vue docs for accessing props:

Note that if you destructure the props object, the destructured variables will lose reactivity. It is therefore recommended to always access props in the form of props.xxx.

If you really need to destructure the props, or need to pass a prop into an external function while retaining reactivity, you can do so with the toRefs() and toRef() utility APIs [...]

In our case, we already are accessing the props as props.xxx, and we don't need to retain reactivity.

If we were shipping Breeze with ESLint then we would definitely need a solution for this, but I'd probably be inclined to reach out to the rule maintainers and get their view on this specific scenario and see whether it should even trigger the rule. Failing that, I'd probably be inclined to configure the linter to ignore this specific case rather than code around it.

I'm going to close this for now. But I'm open to other suggestions, especially if anyone can find any official Vue documentation that covers this scenario.

[laserhybiz]

see vuejs/eslint-plugin-vue#2268