fix(NcCheckboxRadioSwitch): Pass attrs to input if available

[susnux]

☑️ Resolves

I would expect the attrs on the input element to allow any aria attributes.
So if not button type, pass the attrs to the input element to allow setting aria tags like aria-invalid and aria-errormessage

🏁 Checklist

• ⛑️ Tests are included or are not applicable
• 📘 Component documentation has been extended, updated or is not applicable
• 3️⃣ Backport to next requested with a Vue 3 upgrade

[susnux]

/backport to next

[ShGKme]

Why don't pass to the button as well?

[susnux]

Why don't pass to the button as well?

They are as in this case it is the root element.

[susnux]

we maybe should add consistent props for all input elements to have some focus and validation API independent of the implementation.

[ShGKme]

They are as in this case it is the root element.

But it is disabled via inheritAttrs: false here

[susnux]

For vue2 class and style are passed to the root as they are not attrs but somewhat special

[susnux]

https://v3-migration.vuejs.org/breaking-changes/attrs-includes-class-style#_2-x-behavior

[ShGKme]

Why don't pass to the button as well?

Here I meant the attrs, not only class/style.

[ShGKme]

Currently there is a new possibility to pass attrs to input, but the possibility to pass attrs to the button has been disabled.

[susnux]

No for button type they are passed:
https://github.com/nextcloud-libraries/nextcloud-vue/pull/5507/files#diff-80b068a320cd09d28f4f8913f4c77c73754bed31f69a9b3a25353059d8573623R279

[susnux]

So class & style are always set to the wrapper.
attrs are passed to the wrapper (the button) for button type and to the input for other types.

[ShGKme]

Oh, sorry, missed this line.

[skjnldsv]

Breaks server nextcloud/server#46239
we can't apply attributes to the outer span now, that is an issue imho

[susnux]

we can't apply attributes to the outer span now, that is an issue imho

The structure of components is private and can change anytime, thus assumptions about it will always be prone to break.
That is why we have e.g. content-classes etc for assigning custom classes to dialogs without any assumption about internal class names or structure.
In this case you have a checkbox thus you would expect to have a checkbox element (input).

This "regression" is only about tests that assume some specific internal structure, but it is more a fix.

If you currently have cy.get('[data-cy-my-checkbox] input') you could simplify to cy.get('[data-cy-my-checkbox]') or the most secure way: cy.findByRole('checkbox', { name: 'My checkbox' }) which will work regardless of the internal structure and only depends on your app code (the accessible name that you assign).