Warn destructing attrs & slots

[jd-solanki]

Please describe what the rule should do:

What category should the rule belong to?

[ ] Enforces code style (layout)
[x] Warns about a potential error (problem)
[ ] Suggests an alternate way of doing something (suggestion)
[ ] Other (please specify:)

Provide 2-3 code examples that this rule should warn about:

setup(props, { attrs, slots }) {
  const { slotFoo, slotBar } = slots
  const { id, hidden } = attrs
}

Additional context
According to vue docs, destructured attrs & slots aren't reactive. Hence, we should not destructure them in setup function.

attrs and slots are stateful objects that are always updated when the component itself is updated. This means you should avoid destructuring them and always reference properties as attrs.x or slots.x. Also note that, unlike props, the properties of attrs and slots are not reactive.

EDIT: Sample code updated, Thanks @FloEdelmann

[FloEdelmann]

We have a similar rule: https://eslint.vuejs.org/rules/no-setup-props-destructure.html

Maybe it could be modified to also check attrs and slots.

[FloEdelmann]

Related to #1949.

[ota-meshi]

Hmm...
I don't think attrs and slots are reactive, destructured or not.

So they should be used more carefully. I find it difficult to check well.

For example, use onBeforeUpdate to handle:

setup(props, { attrs, slots }) {
  let { slotFoo, slotBar } = slots
  let { id, hidden } = attrs
  // ...
  onBeforeUpdate(() => {
    ;({ slotFoo, slotBar } = slots)
    ;({ id, hidden } = attrs)
    // ...
  })
}

Using destructuring, but I don't think the above is wrong.

[jd-solanki]

I don't think attrs and slots are reactive

They are stateful as mentioned in docs

[ota-meshi]

Yes. In other words, the example code you provided is neither right nor wrong.
Even with destructuring, it will probably behave correctly depending on how the value of is handled.

setup(props, { attrs, slots }) {
   const { slotFoo, slotBar } = slots
   const { id, hidden } = attrs
}

What would your proposed rule check for?

[jd-solanki]

What would your proposed rule check for?

It will assure that we don't destructure the attrs & slots.

In my lib anu-vue I previously had this destructuring which was causing reactivity lost.

E.g. If I pass type attribute as ref and change it via button click then its type value doesn't get updated from text to password.

Thanks.

[ota-meshi]

Did you fix it? I think the attrs.id of the main branch is still lost in reactivity.

https://github.com/jd-solanki/anu/blob/6796c843812cb9ec3cd1e0cd337866df40967439/packages/anu-vue/src/components/base-input/ABaseInput.tsx#L24

[jd-solanki]

I think the attrs.id of the main branch is still lost in reactivity

Let me check

[jd-solanki]

Below code in my playground is working fine on main branch:

<script lang="ts" setup>
import { ref } from "vue";

const inputType = ref("password");
const toggleType = () => {
  console.log("clicked");
  inputType.value = inputType.value === "text" ? "password" : "text";
};
</script>

<template>
    <AInput :type="inputType" modelValue="text"></AInput>
    <ABtn @click="toggleType">Toggle type</ABtn>
</template>

It is working fine:

Now even docs is confusing me 🤣

It states attrs & slots "stateful objects". Moreover, there's also "properties of attrs and slots are not reactive".

IG someone better than me needs to comment on this or I should try this in SFC playground.

[ota-meshi]

Can you provide a SFC playground link to try out your components?